Stream: Coq Platform devs & users

Topic: Snap vs. Flatpak vs. AppImage


view this post on Zulip Karl Palmskog (Apr 24 2022 at 10:17):

So not sure everyone here is aware, but there seems to be an ongoing power struggle between app delivery formats in the Linux world. My feeling from reading lots of forum posts is that many people really don't like Snaps and/or the Snap store. Their choice is then apparently Flatpak, but then there are also AppImage proponents. To give one example, the newly released Ubuntu 22.04 LTS delivers Firefox via a snap, and this broke things like Gnome extension installation, which annoyed the anti-Snappers.

We probably don't have the manpower to do, for example, both Snap and Flatpak, but if we ever got the manpower to do this, it may be a good idea.

view this post on Zulip Enrico Tassi (Apr 24 2022 at 13:48):

I gave a look at the other formats s while ago. Back then snap was just better. These issues of system integration don't really apply to us, and in any case th e benefit is much higher. I did install Firefox via snap even before to this switch.

view this post on Zulip Enrico Tassi (Apr 24 2022 at 13:50):

Of course we can support more formats, if someone has the time.

view this post on Zulip Karl Palmskog (Apr 24 2022 at 13:54):

the main argument against Snap may be that it's completely controlled by Canonical, and people may refuse to use it for that reason (compare Windows Store, I guess)

view this post on Zulip Karl Palmskog (Apr 24 2022 at 13:56):

since Coq strives to be "open source" / "open science", the central control by Canonical over Snap may be perceived as a problem further on. I'm not advocating adding more formats now, or even in the near future, but we shouldn't be surprised if this criticism is brought up repeatedly as the Platform increases in popularity

view this post on Zulip Théo Zimmermann (Apr 24 2022 at 14:03):

I don't like that Canonical / Ubuntu is promoting Snap over traditional Debian-style package management. But I don't think we need to care too much about the control exercised by Canonical over Snap much like we shouldn't worry too much about the control of Microsoft over Windows Store or Apple over App Store (where I think it would make sense distributing binary installers eventually). To address the concerns of people who refuse to use Snap we already have the interactive script installation method, and we should complete that by making it easy (with documentation) to package the Platform in other packages managers -> this is really what being open is about.

view this post on Zulip Karl Palmskog (Apr 24 2022 at 14:13):

the difference from Windows and Windows Store is that we already have a standalone binary Windows installer. The closest on Linux may be AppImage, which seemingly is just a big file you can do operations on/with.

view this post on Zulip Enrico Tassi (Apr 24 2022 at 18:39):

Having one store has some advantages, first is good hosting and second a global index of versions, aliases, statistics... IIRC the code of snapd is free and there is one line to change to point to another store. But nobody did come up with an alternative store. There is a pr/issue about that and the discussion explains why the multi store idea is not just better.

About regular deb vs snaps, they are really designed for different things. You cant possibly update a standard ffox package as easily as you do with the snap, it has tons of deps which you want to just vendor and that is not compatible with the model of debs. Similarly deb run code as root at install time, while snaps are confined: a deb coming from untrusted or incompetent source is a bomb. You can't build a store like thing on deb.

When I started working on the snap I did look at the other 2 formats which were nowhere near in terms of documentation and ease of build or use. This may have changed.

view this post on Zulip Michael Soegtrop (Apr 25 2022 at 08:39):

We also have an active maintainer of debian packages for Coq (@Julien Puydt) - for release timing reasons it is not really possible to make it 100% Coq Platform compatible, but at least we are in contact and try to make things as smooth as possible.

IMHO Snap + debian packages + install from sources should be sufficient.

I sometimes wonder if it would make sense to equip Opam with some sort of binary cache (for some preferred OCaml version).

view this post on Zulip Enrico Tassi (Apr 25 2022 at 08:56):

Apparently you are not alone https://github.com/ocaml/opam/issues/629 but the answer to the caching feature is not very satisfactory

view this post on Zulip Guillaume Melquiond (Apr 25 2022 at 08:57):

I thought that opam bin was working well. Isn't that the case?

view this post on Zulip Enrico Tassi (Apr 25 2022 at 08:59):

Hum, did not know about that!


Last updated: Jun 03 2023 at 05:01 UTC