On 12/21/2017 11:15 AM, Dirk Hohndel wrote: > >> On Dec 21, 2017, at 6:54 AM, Henrik B A <hen...@synth.no> wrote: >> >> On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel <d...@hohndel.org >> <mailto:d...@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.
Don't forget the dinosaurs (like me) that build from source :) Philip > > /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 > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
