Re: Packages grow, no longer fit on a 💾

[kiasoc5]

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