Re: Packages grow, no longer fit on a 💾

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

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

I wrote:

> there are also new big dependencies being pulled in for what, from a
> distance, doesn’t really add functionality.

To me, Emacs is still Emacs, with or without libgccjit.  Of course JIT
is an improvement, I don’t deny that, but what I mean is that I still
use Emacs for the very same activities.  This is even more true for
polkit, because I don’t interact directly with it.

> 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. :-)

It should probably be disabled, yes.

>> 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’.

Yes, that’s the kind of figures we need.

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

Right, and reportedly, Alpine-based images for things like Python are
smaller than what we do.  There’s no cheating here: images are
self-contained.

Maybe a good topic for a sub-group at the Guix Days?  :-)

Ludo’.