Flatpak package

[pdureau]

Thanks a lot for your great work. I use Transmission since early 2008 and I am very happy with it.

I would love to install and update Transmission GTK as a flatpak package, because of the sandboxing (useful for an application receiving and sending so much on the net) and to get the new versions directly from the Transmission team.

So, I wrote a flatpak manifest file for building Transmission GTK from HEAD as a flatpak package against the Gnome 3.22 runtime. You can find it here: https://github.com/pdureau/flatpak-manifests It works!

Have you planned to adopt flatpak to distribute Transmission GTK (and maybe Transmission QT)?

[probonopd]

@pdureau please check #92

[pdureau]

AppImage is a great technology, it is an easy to build, easy to share, package format. And it is nice to have an AppImage for Transmission thanks to @fusion809

Flatpak is not as straightforward but has strong advantages:

• smaller packages thanks to the gnome runtime dependency (no need to include a full CentOS 7 Docker container into the app): my flatpak for Transmission GTK is only 1.6MB compressed (12.3MB uncompressed), 10% of the AppImage size
• automatic updates, because the app can reference its repo (hmmm... maybe AppImage too: https://github.com/probonopd/AppImageKit/blob/master/AppImageUpdate.AppDir/README.md )
• sandboxing (an AppImage is as secure as a normal Linux app is)
• desktop integration (search provider, desktop launcher, dbus desc...) with the exports system

So, IMHO, the best is to provide both.

PS: @probonopd, if my analysis is wrong, please tell me. I love both AppImage and Flatpak and I don't want to spread BS.

[fusion809]

Ya missed a disadvantage though. AppImages are run as is, while Flatpaks are installed first. Installing a Flatpak requires admin privileges, not all users have those rights. So AppImages have the advantage there.

[fusion809]

I may be wrong, I suppose if you install it with the --user option it might only need the user's password as it does install to ~/.local/share/flatpak in that case.

[pdureau]

With the --user option, no user password is needed (because the user has writing rights on his own ~/.local/share/flatpak directory).

I am very pleased about the "no install" part of AppImage, even if it reduces the desktop integration. It remembers me http://portableapps.com/ from the Windows universe.

I don't see Flatpak and AppImage competing. They are very different and fits distinct needs. I want both to success. (To be honest, it is the Flatpak VS Snap issue which is bothering me a bit)

[fusion809]

Well I know that Snaps are easier to package, in my limited experience. I've never been able to write a Flatpak due to how much of a pain in the backside it is. I have been able to create a Snap (granted I had modified it from an existing one, but I couldn't even manage that with Flatpak, rofl). But Flatpaks seem like the winner as they're being more widely adopted by upstream projects over Snaps. Most notably GNOME and KDE.

[probonopd]

Agree that having both doesn't hurt. Some thoughts far as the comparison goes:

• Flatpak for Transmission GTK is 12.3MB uncompressed is about the same as the AppImage compressed. However the AppImage is kept compressed at all times and does not need a Flatpak runtime
• AppImages can carry update information for AppImageUpdate, and can do binary delta updates, which means you only download the bytes that have actually changed between builds
• AppImages can be run in different sandboxes such as Firejail (which has native support for it), or Bubblewrap (which Flatpak uses too)
• Unlike Flatpaks, AppImages can run on Live CDs and Live ISO systems
• You do not need any tools to manage the software, simply download one file, and be done with it. Easy to share with a friend, too
• It is very easy to archive applications for future reference

[pdureau]

We are living in a very interesting time for Linux apps packaging. Thanks to people like you, Simon, and @alexlarsson.

I would enjoy to see both a Flatpak file and a AppImage file in the official Transmission download page: https://transmissionbt.com/download/

Maybe soon...

[probonopd]

Since the Transmission project does not provide an AppImage yet, I took a different route and converted the existing binaries in the ppa to an AppImage.

The AppImage contains Transmission as well as the needed libraries which cannot be expected to be part of every target system. It is expected to run on most 64-bit desktop Linux systems.

Download it from here:
https://bintray.com/probono/AppImages/Transmission/_latestVersion#files

Just set the executable bit and run. No installation, no system libraries touched, no root needed. Should not interfere with any other versions you might or might not have on the system already.

This file specifies how to translate the ppa into an AppImage:
https://github.com/probonopd/AppImages/blob/master/recipes/meta/Transmission.yml

I think this would be a good way to provide nightly/continuous builds. It is almost no extra work if ppa builds are available for trusty or earlier.

It works nicely for me on an Ubuntu 16.04 system. However, it is expected that some fine-tuning and additional testing may be needed, and some fine-polish needs to be done by someone who knows the inner workings of the application.

It would be nice if the upstream project would start providing AppImages of nightlies.

[mikedld]

This is nice, but I'm not sure what is expected from us here? I understand that some people are excited about this kind of stuff, and I see that you already have repositories and packages ready...

I personally don't like the idea as it bypasses system package manager which each distribution (including those mentioned in #92) has, unlike Windows or Mac (Windows Store and Mac AppStore are not the same thing), and doesn't seem to bring anything I'd want to the table. Package managers keep system organized, they are a single source of truth about what, when and where on disk is installed. And getting "new versions directly from the Transmission team" might even be a downside: I put trust in package maintainers (and people using unstable versions of those packages) to be an additional line of defence against breaking my system or losing data (shit happens anyway, but that's another story).

That said, PPAs (and similar) exist for a reason. Never say never, but I think now is a bit early.

[probonopd]

getting "new versions directly from the Transmission team" might even be a downside: I put trust in package maintainers

Let's not see it as an either-or, but as an additional option to get software.

[haevalencia]

@pdureau You could contact and add the application in this list (currently there is only transmission-remote). Also if you are interested you could contact the Endless OS community as the help is always welcome and having trasmission would be great.

@mikedld Your comment reminds me a lot of how I used to think of Ikey Doherty and it's true, however, not all development teams offer as many distribution options as you do. Currently some distros already use Flatpaks especially for third party software and others will change to this in the short term future (Ex. Solus OS).

[wjt]

For the record:

• I created a Flatpak for Transmission-Gtk for Endless OS a few months ago. (It's our recommended BitTorrent app.)
• I've just submitted it to Flathub. Flathub's policy, as I understand it, is to allow third-party packagers, and to hand over the package repo to upstream on request.

[ckerr]

I'm tempted to close this issue since the Transmission team doesn't really have the available bandwidth to maintain one (or three, really, if you add appimage and snaps to the list) but I love it that people are maintaining third-party binaries of this. E.g.if @wjt is maintaining flatpaks on Flathub, that's wonderful.

Unless there's a low-effort way -- to be honest, a very low-effort way; we're pretty short-handed -- for this to be done by the Transmission team, it's probably for the best that this be left downstream.

[wjt]

FWIW I don't have a great deal of time to actively maintain the Flathub Flatpak for Transmission. I'd appreciate additional hands if Transmission releases are likely to flow thick and fast :-)

[Pentaphon]

I'm tempted to close this issue since the Transmission team doesn't really have the available bandwidth to maintain one (or three, really, if you add appimage and snaps to the list)

I think appimage and snap are completely unnecessary. Flatpak is probably the most used of the 3 right now and will be for the foreseeable future. If anything, Flatpak should become the default way to install Transmission on all distros besides the repos that each major distro maintains for and those 2 ways to get Transmission are more than enough for Linux users.

I'd appreciate additional hands if Transmission releases are likely to flow thick and fast :-)

I think this project needs as much help as possible but considering that Transmission gets an update every 1 or 2 years these days, you will probably have more than enough time to maintain it and people like me will be sure to notify your Flatpak repo when there's a new version.

[ckerr]

Well, releases will probably happen slightly more frequently after the development work that's been happening since last October or so, but... yes, it'll still be reasonably slow.

[ckerr]

I'm closing this issue for the reasons listed above.

I love the idea of users having more ways to get & run Transmission -- I just don't have the bandwidth to maintain it.

If someone wants to maintain a flatpak package and make it available somewhere, that would be great! Please open a PR for the transmission/transmission docs linking to it to help users find it!

[wjt]

Where in the docs should I link to the Flatpak of Transmission which is available on Flathub?