Subsurface as a Snap?

[Lubomir I. Ivanov]

On 21 December 2017 at 17:15, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 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> 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
--