Re: Packages grow, no longer fit on a 💾

[indieterminacy <indieterminacy@libre.brussels>]

On 18-01-2023 03:41, kiasoc5 wrote:
> 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

I think Guix is missing a trick here.

All this effort to chain everything with inputs and yet we are using 
conventional 'package-boxes'.

Why not 'Dutch Auction' it and set a maximum amount of inheritants 
within one package file and then iteratively lower the threshhold (over 
time!) until there are noises in the guix-devel ML
that this principal is being taken far.

The outcome could allow more of a layers and multifaceted representation 
of tools and applications that give more of a distinction between lower 
level utilities and applications.


-- 
Jonathan McHugh
indieterminacy@libre.brussels