Subsurface as a Snap?
dirk at hohndel.org
Thu Dec 21 07:15:53 PST 2017
> On Dec 21, 2017, at 6:54 AM, Henrik B A <henrik at synth.no> wrote:
> On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel <dirk at hohndel.org <mailto:dirk at hohndel.org>> wrote:
> Snap and Flatpak both are different takes on what we already have with AppImage.
> The goal of AppImage was to have fewer builds to worry about. And it brilliantly does that.
> So unless there is something that is a) better and b) completely replaces AppImage, I'm
> not sure why we'd spend time on it.
> It was just a thought. With Ubuntu (and others) embracing Snap, and with all major distributions supported, and a central package repository available, it might reach a larger user base and be easier to support. I obviously base this conclusion on absolutely nothing :D
Let's talk Linux Distro Politics here.
Snap is a Canonical effort and as such is receiving at best "lip-service" level support from the other distros.
FlatPak was very much developed by Red Hat as a response to Snap and as a direct competitor.
As a result (isn't it lovely), neither of them has good support on the other one's platform. Even though both of course claim that they do.
AppImage, conversely, isn't controlled by either of the vendors but instead developed and driven by the community.
Its design goals seem to very closely match our desire for an independent, broadly supported packaging format that does NOT require any other software to be installed on the target system. But on the flip side, the user experience usually isn't quite on par with a natively supported app.
Yes, I agree that the repositories and distro integration for Snap and FlatPak on their respective "home" platforms are attractive. It has been my perception that the incremental value would be small compared to the effort this would take to develop and most importantly maintain.
I could be wrong (that's one of my defining strength - I am wrong a lot). But here's my analysis:
About 2/3 of our users are supported with one single binary, the Windows installer.
Another 20% of our users are supported by one single binary, the Mac DMG (we had times had a second DMG for older versions, but given that they tended to get < 100 users, I have not spend much effort on them).
The remaining roughly 15% of our users today require us to build about 30 different binary packages which take up a significant amount of my time whenever we introduce a new dependency, need a feature from a newer version of a library, or some other way break things. At this point I have managed to bring down the number of build configuration systems to 3 to create the vast majority of those binary packages: the Ubuntu/Launchpad system, the openSUSE/Fedora/OBS system, plus AppImage. Additionally, community members are maintaining always current and very solid binary packages for Arch and Gentoo (I believe). Considering this maybe you can understand my reluctance better.
PS: Oh, and of course there are the additional two build frameworks that we support for Android and iOS, because maintaining 5 different ones clearly wasn't crazy enough.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the subsurface