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.
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.
Of course we can support more formats, if someone has the time.
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)
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
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.
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.
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.
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).
Apparently you are not alone https://github.com/ocaml/opam/issues/629 but the answer to the caching feature is not very satisfactory
I thought that
opam bin was working well. Isn't that the case?
Hum, did not know about that!
Last updated: Jan 30 2023 at 12:03 UTC