On 1/17/23 11:25, Ludovic Courtès wrote:
There are slight increases of each and every package, and there are
also
new big dependencies being pulled in for what, from a distance,
doesn’t
really add functionality.
Examples include libgccjit in Emacs and mozjs in polkit.
In a way, that’s the “unavoidable” (?) evolution of software, and the
problem extends largely beyond Guix.
Still, even compared to contemporary distros, we’re doing pretty bad.
Debian most likely does better, and people often cite Alpine as the
distro providing the smallest packages. Do we have figures? What can
we learn from them? What tradeoffs to they make?
We can achieve smaller packages by splitting them more. Here is my
guess of the amount of package splitting by some distros, from least to
most:
Slackware < Arch < Fedora < Debian < Alpine
- Slackware I believe does not split anything, everything is included.
- Arch splits packages on a case by case basis (QEMU for example)
- Fedora typically splits packages into package X and package X-devel,
where X contains development headers, but usually not more.
- Debian splits packages more aggressively. For example libreoffice is
split into 6 packages, 1 for each suite (draw, write, etc). And
programs may be separated from their outputs (eg zstd and libzstd are
split)
- Alpine splits even more aggressively, they also split out man pages
and shell completions.
We may wish to utilize multiple package outputs to a greater extent.
Some Guix packages already have bin, doc, and lib outputs. We could
make it a policy to split this for all packages.
I also wonder how much of the space is taken by debug output. Would
making graft derivations substitutable help?
https://lists.gnu.org/archive/html/help-guix/2022-10/msg00225.html