Context
In more than a decade of FreedomBox’s partnership with Debian (i.e. being a pure blend) we have encountered some applications that are desirable to have in FreedomBox but near impossible to maintain in the form of Debian packages. This is a discussion thread to talk about alternatives to Debian packaging for FreedomBox applications.
Problems
Dependency explosion: Some web applications have hundreds (e.g. CryptPad) to thousands (e.g. GitLab) of dependencies. Debian requires that every one of these dependencies along with the application itself to be available as Debian packages. This is unlike packaging for F-Droid, for which we packaged only the FreedomBox Android app, and not every dependency of the app.
Keeping up with updates: Applications like NextCloud require us to go through every update, i.e. we can’t jump from NextCloud 20 to 25 because Debian stable versions are 2 years apart. The application becomes unusable otherwise. Debian Fasttrack is meant to solve this, but because of problem #1 we won’t be able to keep up.
Requirements for Alternatives
We need alternatives to provide us with
the same security and privacy guarantees as Debian packages (with the ability to apply our own patches)
the ability to deliver updates quickly, at least for every major upstream release
interoperability with already installed system packages from Debian, such as databases and web servers
(nice to have) low memory footprint
The alternative packaging system must leave the existing FreedomBox applications undisturbed.
Out of Scope
Please focus on packaging systems in this thread, avoiding adjacent topics like
A new kind of FreedomBox not based on Debian
Running other self-hosting systems like Yunohost or Libreserver on top of FreedomBox
If there are other threads discussing a certain packaging system in detail, please link them below.
With Fasttrack in place, the 2 problems boil down to just the dependency explosion.
This is unlike packaging for F-Droid, for which we packaged only the FreedomBox Android app, and not every dependency of the app
Debian’s request to have every code bit as a Debian package expresses the need to keep everything under control. That underlying need remains.
Today FreedomBox only trusts Debian. We might decide to extend our trust to other entities (like Pipy, Maven Central, or NPM), but this is a dangerous decision that ought to be sparsely taken for a reduced number of entities.
For example
All of the three mentioned entities have their package managers packaged for Debian,
The software in their repositories is highly interoperable with Debian,
Interoperability among the applications from these sources:
Virtual environments allow the coexistence of different versions of the same Python packages,
Maven allows such coexistence by design
I don’t know, but I guess and believe that NPM does as well.
But this coexistence of different versions raises the question of security: Most likely a lot of older versions will no longer be maintained! Are we willing to take responsibility for the security of thousands of sw bits on our own? I believe that packaging them for Debian might be less burdensome.
I understand that FreedomBox would only include selected applications that provide and care about privacy.
After this back-of-the-envelope (shallow) analysis, I believe these “adjacent topics” are in fact very relevant to this discussion.
I have been following Guix Linux for a while now, and even used it for a brief period on my home laptop (stopped because combined intel/nvidia GPU driver support was funky, and I’m more familiar troubleshooting those things in Debian/Ubuntu). I think that it would meet all your criteria nicely. Either as a base OS, or as a package manager. https://guix.gnu.org/
Their philosophy aligns nicely with Freedombox as well.
In my experience using Guix as a package manager on top of another GNU/Linux distro:
guix pull results in several minutes of full usage of the CPU of my T400, apparently building things.
this operation does not update any package, guix package -u needs to be run in addition to update packages.
I noticed that this update process was fetching more than 50 packages (I did not count) while the only guix packages I had installed were fonts, locales and gajim. Should a substitutes be missing for one of them (it happens), my PC would build it and it could take a while (10 minutes at least usually, but when I had installed ungoogled-chromium, it happened once to be 3 days).
On a machine like the Pioneer, build times should be much longer. In addition, the availability of substitutes is much lower for architectures other than x86. Perhaps guix could be a solution but should it be used for Freedombox, it would be necessary to ensure the availability of substitutes for all “dependencies” (all the things that get downloaded at updates although they don’t look like dependencies in the Debian sense).
As the blog post in my previous comment suggests, Nix could be used on Debian. Nix can provide many desirable packages such as Nextcloud, FreshRSS and Matrix Synapse, plus we wouldn’t have to deal with dependency issues anymore.