Provide Snap official alternative

[julian-alarcon]

Hi
It will be great is besides the current Flatpack version, you can also provide Snap version!

The good thing about this is that Snap is native to Ubuntu and every Ubuntu user will be a command/click away of getting latest version!

Se the comparison of versions in Ubuntu 18.04 (Snap vs .deb) snap version is unofficial but newer!:

julian@EN911054U:~$ sudo snap search handbrake
[sudo] password for julian: 
Name          Version  Publisher  Notes  Summary
handbrake-jz  1.1.1    jz         -      The open source video transcoder
julian@EN911054U:~$ apt search handbrake
Sorting... Done
Full Text Search... Done
handbrake/bionic 1.1.0+ds1-1ubuntu1 amd64
  versatile DVD ripper and video transcoder (GTK+ GUI)

handbrake-cli/bionic 1.1.0+ds1-1ubuntu1 amd64
  versatile DVD ripper and video transcoder (command line)

Maybe you can reuse the work done by @jacobzimmermann here:
https://github.com/jacobzimmermann/handbrake-jz-snap/

[jstebbins]

The good thing about this is that Snap is native to Ubuntu and every Ubuntu user will be a command/click away of getting latest version!

This sounds more like a negative to me. I would prefer it if every distribution could consolidate on one and only one containerized distribution method. One of the key points of containerizing is to make the application runnable across multiple distributions using a single package. If I had to produce a separate package for every distribution because "it is native to X" and therefore better in some mysterious way we would be right back where we started having to produce different packages for every distribution.

In the long run, I don't mind producing a few of the most common containerized formats. And it looks like snap may become a "common" format. But I'm waiting for the dust to settle a bit before committing a lot of effort to it. I only chose Flatpak because it's "native" to Fedora which happens to be my development platform. Docker is another "common" format I may support. We'll see. Maybe somebody would like to help support some of this?

[ssokolow]

Honestly, I wouldn't put much hope on snaps.

1. The reason it got as much traction as it did is that Canonical made a huge "Java by Sun Microsystems" marketing push, did a lot of spin-doctoring and paid people to implement support in other distros, and claimed what they implemented was more complete than it was... support that's now going stale.
2. Even Ubuntu-based distros like Mint are setting APT rules to blacklist snapd to make sure Canonical's "the chromium-browser package is a dummy package which will pull snappy back in if you've uninstalled it" dirty tricks don't contaminate their distro.
3. Personally, I can say that Snap is a technically inferior system. Snap-packaged applications start significantly more slowly (Flatpak apps didn't take a noticeably longer time than APT-installed stuff for me, even before I switched to an SSD) and it crowds out the useful information in your mount output with a flood of loopback mounts.
4. I don't have a single citation handy, but, while looking into future options for packaging my own creations, I ran across various pieces of evidence that snap is still struggling to achieve the level of sandboxing that Flatpak does and the current solution to various desktop integration woes is to take advantage of snappy's support for building unconstrained packages. (Because snappy merges the functionality of Flatpak and the functionality of using the underlying OSTree system directly, while Flatpak draws a clear distinction between sandboxed desktop application packages (Flatpak) and fundamentally unsandboxed packages for immutable distros like Fedora Silverblue (OSTree).)
5. If you don't want to use Ubuntu's snap repository, you basically have to reimplement it, because they're keeping parts of the server-side stuff proprietary. Flatpak was designed from day one with the intent that, like traditional package managers, anyone should be able to publish a repo if they want to.
6. While not damning, it is telling that all the stuff shared between Flatpak and Snappy (eg. the XDG portal system) is stuff that was developed for Flatpak and then adopted by Snappy. (Snappy banked heavily on "first to market" by releasing an incomplete product and covering that up using the ability to set a package to have no sandboxing.)
7. Last I checked, snappy had little to no support for dependency deduplication, while Flatpak combines platform runtimes with OSTree's own deduplication capabilities.

Snappy is the new Mir or upstart.

[robxnano]

I'm currently working on making this happen. So far I've got a working Snap build of HandBrake which is just about ready for testing, but I had to make a few big changes due to quirks in the way Snap packages are built and versioning issues with the libraries provided by the platform snaps, and also to keep the size down. So at the moment it builds from the snap branch of my fork.

• Replace the autoconf build system for the GTK client with Meson
• Make all contrib libraries buildable as shared
• Allow use of the correct libdir for the shared libraries

Assuming you're okay with having an official Snap release, I can send the PRs to get these merged, and you can sign up for an account in order to manage the releases.

[jstebbins]

An official snap is fine with me. Meson change is good. I wanted to do that as well and actually made some progress on it at one point.

What's the reason for switching to shared libs? Seems like an invitation for trouble with conflicts with the snap system. Potential inadvertent substitutions of snap system libs and all. We build anything we don't want substituted static to prevent such accidents/conflicts.

[robxnano]

There were two main reasons. The first was to save space by allowing the GUI and CLI binaries to share the libraries. The second is harder to explain, but here goes: To get the preview support to work, the gstreamer-libav plugin is required. This needs to be linked against the ffmpeg libraries, and the easiest way to do so was to reuse the ones from the HandBrake build process. I first tried adding the Ubuntu package, but this pulled in a lot of other dependencies that caused conflicts with the libraries in gnome-platform so it wasn't a viable option.

Converting the libraries to shared versions allows the plugin to use HandBrake's ffmpeg, which in turn links to x264, x265, and the other media format libraries. Yes, this does increase the risk of conflict when the gnome-platform snap is updated, but there would still be a risk from the other shared libraries taken from the Ubuntu repositories. I can keep looking for alternative solutions though.

[jstebbins]

This is a bit of a ramble... I think the most important point is at the end, so I'll repeat it here. IMO this approach pushes some problems into the future at an uncertain point in time when the collective we may not have the time or motivation to fix the problems.

Ramble ON...

So my concerns are that this risks breaking both gstreamer (since it is tested to work with the packaged version of ffmpeg) and HandBrake (since our shared libs could get superseded by the snap system). There are a few weight weenies out there that are concerned about size, but they are the vocal minority. I wouldn't be concerned about that 😁

I'm not familiar enough with how snap packages things to be of much help with the gstreamer conflicts, but if there isn't a relatively simple solution to that, then snap is fundamentally broken (which would not surprise me frankly). And if that's the case, there's a good argument for delaying this till snap is more fully baked.

Assuming we create a snap that uses shared libs... If we were to run into an issue after releasing the package, my feeling is we would have to revoke the snap and remove it from the snap store until we found a solution (which could take some time). So the questions become...

1. How likely is the hypothetical gstreamer breakage to happen?
2. How likely is the hypothetical HandBrake breakage to happen?
3. How difficult is it to remove something from the snap store?
4. How many users would we be pissing off by revoking a published package (i.e. what kind of support headache do we create)?
5. What do we tell users of the broken snap package to do as a backup solution until we can fix the problem?

I think the answer to 1 is, eventually it will happen because there will be a major ffmpeg version difference eventually between what we ship and what Ubuntu ships. A potential solution would be to also ship our own version of gstreamer and gstreamer-plugins. But that's yet another rabbit hole I'm afraid.

I can't answer 2. There may be certain guarantees built in to snap's design and packaging policies that would completely prevent it. I just don't know.

Regarding 3, people tend to get really ticked off when you give something, then take it away. So we have to consider the bad publicity this could result in and the impression it would leave behind. Again, I don't know snap details, so can't answer to the mechanics of doing this.

The answer to 4 is pretty small on a percentage basis, but big enough to cause support grief in the forums (answering the same question even just 20 times gets old).

The answer to 5 is to revert to what we currently tell Ubuntu users, install flatpak and then install HandBrake from flathub.

So after writing all this down... given that the gstreamer breakage will happen as some point, my opinion is that this is a no-go until we can solve these problems. Putting it out there with these things bandaided over is going to create headaches for someone at some future time when they may not have the time or desire to rectify the problems.