Google-play-music-desktop-player-unofficial-: Feature Request: Make GPMDP Available Through Standard Repositories (Linux)

Created on 4 Jun 2017  路  21Comments  路  Source: MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-

OS:

Linux flavors (Debian/Ubuntu/Mint/Fedora)

Issue Descriptions:

Linux users like the ability to have their apps updated automatically. This is usually achieved by offering the application offered through the distro's standard repositories (apt-get and a PPA in Ubuntu, dnf via a COPR in Fedora).

As it currently stands, anyone who wishes to update must revisit the Google Play Music Desktop Player website, see if there's a new version available, and then download it.

The request is to add a PPA repository for Debian/Ubuntu and a COPR for Fedora to build and grab the GPMDP .deb and .rpm files.

Steps to Reproduce:

N/A

Most helpful comment

All 21 comments

The thing is that building node.js apps with on the Launchpad build farms is impossible due to the external resources restrictions in place there, which basically deby any access to resources outside of Launchpad itself. Since Node.js (and Electron) need the npm repository, they can't be built directly out of a PPA.

The "next best thing" is to have a place where Linux flavors can check for updates on already compiled deb or rpm files (like other popular electron apps do, like VS Code or Atom).

The next next best thing would be to make it available as a snap package.

The "next best thing" is to have a place where Linux flavors can check for updates on already compiled deb or rpm files (like other popular electron apps do, like VS Code or Atom).

Failing an open repository, how difficult would it be to simply ping the GitHub page (or wherever builds are hosted) whenever the application is initially launched and notify the user if the version number in the repository is newer than the version currently installed on the user's system?

The key thing to understand here is I am literally one person currently maintaining 3 platforms and 4 release channels (including an existing PPA repository).

There is a snap package somewhere as well.

The only thing I see in this issue set which isn't already a thing is an artifact repository for fedora based systems which I have even less idea how to set up than I did a debian repository.

If someone wants to setup / maintain linux deployment pipelines I'd be more than happy to set up any automated pushing / notifications you may need to get it working but I don't think I can maintain another deployment channel.

If someone wants to setup / maintain linux deployment pipelines I'd be more than happy to set up any automated pushing / notifications you may need to get it working but I don't think I can maintain another deployment channel.

I have no experience with it, but I'm reading through the documentation for setting up a COPR and it seems possible. I'll play with it and see if I can make any headway.

The issue remains that you won't be able to ping GitHub because of the restricted external resources pulling policy. There is simply no way to automate the deployment process through those.

I'm looking at Bintray's Open Source plans to see if it can allow automated deployment on Debian/Ubuntu.

Bintray is what I am currently using for the debian repository

Oh well...
Bintray can already manage distribution through the default package managers. Users can manually add the bintray repo like this:

deb https://dl.bintray.com/solarliner/gpmdp-test {distribution} {components}

and it will be picked up by apt for automatic updates through it.
I have to check but you can automatically add the repo through the POSTINSTALL script on the .deb file. (like what Atom is doing)

I don't know for RPM though.

... and somehow I never saw it :rofl:

So the only thing remaining is distribution of the app through RPM repositories.

Also, small note for Debian and Ubuntu: on 16.04 and up, apt-get is only provided for backwards compatibility. apt is the most recent version and a better user front-end of the package manager.

So based on the tutorial here, we would either need a src.rpm (I'm assuming this is a middle-step RPM before it gets built for the specific arch's) or a .spec file within a Git repo so that the COPR can figure out how to build the thing.

There's no .spec in the GPMDP repo at the moment (I could look into how one might construct it), and the RPM's from the release section seem to have already been built for the specific architectures.

Is there a src.rpm that gets built somewhere along the way in the current build system that could be preserved to try passing along to the COPR?

@AdmiralAsshat Bintray works with yum repos which would fit @MarshallOfSound's workflow. In this sense, re-building the package just for inclusion to package distribution seems a bit overkill.

@SolarLiner Okay, that works. A separate COPR seemed like the easiest solution, but if @MarshallOfSound is already uploading releases to Bintray and dnf can use it, I am satisfied with that solution.

I don't see any RPMs at the current url. Only a deb directory.

Is he able to easily push the RPM's there as well? If so, I can add instructions to add the URL to yum repos and install via DNF to mirror the deb instructions.

Because it seems that he didn't include RPMs in the deployment server yet.

Is the action item here to add the rpm releases to a bintray redhat repository?

That would work, yes. Thank-you.

In case there are any Gentoo users out there, I maintain a layman overlay where I publish ebuilds of GPMDP, generally within a few days of the latest update.

sudo layman -a zyrenth
sudo emerge media-sound/google-play-music-desktop-player-bin

@MarshallOfSound the icon is missing on the snap version :) best regards

Is it possible to setup the repository automatically when installing the deb package? I know that Google Chrome do it. It's more user friendly than having to do it manually.

I don't know exactly how Google Chrome manages duplicates, but it seems as simple as putting the apt-add-repository lines in the deb postinstall script.

This appears to have been solved with flatpaks. I was able to download the GPMDP as a flatpak through flathub and was visible in GNOME Software. That should solve my issue with wanting automatic updates.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

timp3289 picture timp3289  路  3Comments

greghesp picture greghesp  路  3Comments

logictom picture logictom  路  4Comments

Turbotailz picture Turbotailz  路  4Comments

GeraldNDA picture GeraldNDA  路  3Comments