deb/rpm packages

[bastimeyer]

This is an attempt at creating packages and custom package repos for deb/rpm based package managers.

Due to restrictions of the build/distribution systems of many Linux distros (Ubuntu ppa, etc.), Streamlink Twitch GUI has to build/use its own packages/repos. The reason for this is the way of how NW.js applications are built (NW.js BLOB + App code).

Related issues:
#145 #149

WIP

This feels like reinventing the wheel somehow. The NWjs project does not have any build/packaging tools like Electron does have, so everyone is implementing their own stuff. This is quite tedious and being the only dev here makes it much harder maintaining all this instead of spending the time implementing new features to the app.

Package host

The host I've chosen for this is bintray, because deb and rpm repos can be easily set up there.
Unfortunately, the traffic is limited, so I'm not sure if this will all work.
There are no hosters with unlimited traffic and all others I know about are also far more expensive.

Building the packages

git clone https://github.com/streamlink/streamlink-twitch-gui.git
cd streamlink-twitch-gui
git checkout origin/packages
sudo npm install -g bower grunt-cli
npm install
grunt build:prod
grunt clean:dist dist:linux64deb:linux64rpm

Requires ruby, ruby-dev and fpm to be installed (sudo gem install fpm). Also devscripts and rpm are required (when building on debian based distros).

Checklist

• Use fpm for building packages
  • Write a grunt task for this
  • Deb packages
  • Rpm packages
  • Add package changelogs
  • Add an explicit list of NWjs' dependencies
• Set up bintray account and deb/rpm repos
• Create gpg key for signing the packages
  • Publish key on keyservers
  • Publish key on bintray
• Add travis-ci deploy config
  • Write fix for missing repo metadata recalculation (issue is reported on travis-ci/dpl)
• Sign the packages
  The deploy script of travis is configured to let bintray sign the packages and repos.
  • Deb
  • Rpm
    Having issues with signing the packages and the repo. Packages should be signed, but the repo metadata is invalid and DNF is complaining. Needs further investigation.
• Write an installer bash script
  • Detect the distro and package manager
  • Import the gpg key, set up the repo and install the package
• Disable version check in packaged releases

---

Other options

Maybe Flatpak packages can be the solution to this mess... The adoption of Flatpak in various distros seems to be much higher with Flatpak than with Snap.

[vith]

The host I've chosen for this is bintray, because deb and rpm repos can be easily set up there.
Unfortunately, the traffic is limited, so I'm not sure if this will all work.
There are no hosters with unlimited traffic and all others I know about are also far more expensive.

You may want to look at OpenSUSE's Open Build Service. I haven't used it myself but it can host repos as well as build packages for a wide variety of distros.

OBS project info: http://openbuildservice.org/
Public instance: https://build.opensuse.org/

As an example, here's a random package I found providing repos for Arch, Debian, Fedora, OpenSUSE, and Ubuntu:

project page: https://build.opensuse.org/package/show/home:pbek:QOwnNotes/desktop
repos: http://download.opensuse.org/repositories/home:/pbek:/QOwnNotes/

I believe you can also set up continuous integration.

[NC-VZLA]

Just a suggestion, instead of building for several different distros, why don't test which of the new universal application packages fits better your project.

• Snaps: https://snapcraft.io/docs/build-snaps/
• Flatpak: http://flatpak.org/hello-world.html
• AppImages: https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages

They can simplify your software distribution. Snap is backed by Canonical, but Flatpak appears to have a lot of push on several distros lately. AppImages applications seams to me the easier for the users to install.

[bastimeyer]

Yes, I was thinking about that, but there would still be a ton of issues when building those universal packages. Not to mention that it would still be fairly complex.

The main thing is though that I don't want to spend even more time on this matter when I don't use the packages myself. I'm basically the only developer of the Twitch GUI and I don't have the time also maintaining those packages, as it is quite a burden.

As I've already said multiple times in the other threads, help would be really appreciated.

[NC-VZLA]

Well I'm more of a user level of Linux, but I do follow a Linux show called Linux Unplugged ( http://www.jupiterbroadcasting.com/show/linuxun/ ), one the regular contributors is Mr Alan Pope (AKA Popey) https://twitter.com/popey he works for Canonical and is involved with the snapcraft project if I'm not mistaken, He is, by what I can infer on the show, a very approachable person and may be of more help on this issue.

Hopefully this lead will help to alleviate the burden of distributing the application on Linux somehow.

Thanks for supporting Linux with your software.

P.S.

After googling a bit on the issue looks like snap packages can be built automatically from git repos.
it checks 4 times a day for pushes and build them. This may be the way you don't have to support the Linux packaging directly.

here is the link https://snapcraft.io/docs/build-snaps/ci-integration

---

This is hosted Today by Mr Alan Pope It may be helpful for the automation of Linux packages.

ANNOUNCING SNAPCRAFT DOCS DAY
Snap is a simple archive format for big things.
Snapcraft is a delightful tool for automatically building and publishing software for any Linux system or device. Our documentation and tutorials are great for getting started with snapcraft. We can always improve these though, so this Friday, will be our first Snapcraft Docs Day.
When: Friday, 31st March 2017, all day
Where: #snapcraft on Rocket Chat
Who: Developers & documentation experts of all levels

[eXcuvator]

Recommend against snap. Each single snap adds between 6-10 seconds on boot time for me (and many other users).

[bastimeyer]

I'm going to close this PR now, as I haven't worked on this since at least 2017. I'll leave the branch on the repo though, even if it's very much outdated, just in case...

---

Creating custom deb/rpm packages and hosting them on custom package repositories is something I simply don't want to maintain and invest time in. This is way too complex for someone who's not using these distros. Not to mention all the limitations and restrictions I already had to face during my attempt here.

If NW.js was properly packaged on the distros' official repos or otherwise well maintained custom repos for these distros, then packaging Streamlink Twitch GUI would be much more simple, but this isn't the case.

---

Regarding improving the packaging situation on deb/rpm based distros, I guess going the Snap/Flatpak/AppImage route is the way to go. Personally, I dislike both Snap and Flatpak for various reasons (Snap even more), which makes me not want to maintain those packages as well. AppImage on the other hand seems to be a far saner choice and it also can be built and hosted here. However, I haven't built an AppImage yet and only briefly read the docs a year ago. I'm pretty sure that lots of stuff has changed since then. If somebody wants to help with the creation of an AppImage build config, please check out #616.