On 21 December 2017 at 17:15, Dirk Hohndel <[email protected]> wrote: > > 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]> 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. >
fragmentation is ultimately the biggest downfall of modern software. RedHat and Canonical should combine efforts into a single package tool, but that probably won't happen due to politics and stubbornness. lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
