> On Dec 21, 2017, at 6:54 AM, Henrik B A <[email protected]> wrote:
>
> On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel <[email protected]
> <mailto:[email protected]>> 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.
/D
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.
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
