Re: Packages grow, no longer fit on a 💾

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Tue, 17 Jan 2023 at 17:25, Ludovic Courtès <ludo@gnu.org> wrote:

> Examples include libgccjit in Emacs and mozjs in polkit.

Do I miss a point?  How is it possible to have native compilation for
Emacs without libgccjit?

For emacs-minimal, if considered to only bytecompile (.elc) and not
native compile, this libgccgit seems unexpected, indeed.  Well, is
native compilation disabled for emacs-minimal?  I guess not. :-)


> 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?

I agree we need to improve.  However, I would like to mitigate. :-)

Functional and closure makes apparent what is hard to evaluate on
“contemporary distros”.  I would be curious to know the transitive
closure of the testing Debian meta-package named ’emacs’ (28.2) [1],
which is roughly the equivalent of the Guix package ’emacs’.

Because if you dig a bit [2], for instance it depends on ’libgccjit0’.

If you consider Alpine Linux and give a look at the dependency of the
equivalent [3] of the Guix package ’emacs’, it depends on ’libgccjit’.

These “contemporary distros” rely on version resolver which somehow
hides the costs; when these costs are clearly popping with Guix.

For sure, we need to improve because Docker pack produced by Guix are
really more fat compared to the ones available around and usually
produced with distros as Alpine.

1: <https://packages.debian.org/bookworm/emacs>
2: <https://packages.debian.org/bookworm/emacs-gtk>
3: <https://pkgs.alpinelinux.org/package/edge/community/x86/emacs-gtk3-nativecomp>

Cheers,
simon