[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packages grow, no longer fit on a 💾
From: |
Ludovic Courtès |
Subject: |
Re: Packages grow, no longer fit on a 💾 |
Date: |
Thu, 19 Jan 2023 15:14:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
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’.
- Re: Packages grow, no longer fit on a 💾, (continued)
- Re: Packages grow, no longer fit on a 💾, Akib Azmain Turja, 2023/01/15
- Re: Packages grow, no longer fit on a 💾, pelzflorian (Florian Pelz), 2023/01/15
- Re: Packages grow, no longer fit on a 💾, Ludovic Courtès, 2023/01/17
- Re: Packages grow, no longer fit on a 💾, zimoun, 2023/01/17
- Re: Packages grow, no longer fit on a 💾, zimoun, 2023/01/17
- Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾), Liliana Marie Prikler, 2023/01/18
- Re: Grandfathering store paths considered harmful, Ludovic Courtès, 2023/01/19
- Re: Grandfathering store paths considered harmful, Liliana Marie Prikler, 2023/01/19
- Re: Packages grow, no longer fit on a 💾,
Ludovic Courtès <=
- Re: Packages grow, no longer fit on a 💾, Simon Tournier, 2023/01/20
- Re: Packages grow, no longer fit on a 💾, Maxim Cournoyer, 2023/01/20
- Re: Packages grow, no longer fit on a 💾, kiasoc5, 2023/01/17
- Re: Packages grow, no longer fit on a 💾, indieterminacy, 2023/01/18
- Re: Packages grow, no longer fit on a 💾, Ludovic Courtès, 2023/01/19
- Re: Packages grow, no longer fit on a 💾, Simon Tournier, 2023/01/20
Re: Packages grow, no longer fit on a 💾, Efraim Flashner, 2023/01/17