From: "Ludovic Courtès" <ludo@gnu.org>
To: zimoun <zimon.toutoune@gmail.com>
Cc: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>,
guix-devel@gnu.org
Subject: Re: Packages grow, no longer fit on a 💾
Date: Thu, 19 Jan 2023 15:14:54 +0100 [thread overview]
Message-ID: <874jsmd31d.fsf@gnu.org> (raw)
In-Reply-To: <867cxk224j.fsf@gmail.com> (zimoun's message of "Wed, 18 Jan 2023 00:05:32 +0100")
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’.
next prev parent reply other threads:[~2023-01-19 14:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-14 22:07 Packages grow, no longer fit on a 💾 Ludovic Courtès
2023-01-15 5:51 ` kiasoc5
2023-01-15 8:07 ` Liliana Marie Prikler
2023-01-16 2:09 ` Maxim Cournoyer
2023-01-16 5:17 ` Liliana Marie Prikler
2023-01-16 13:27 ` Maxim Cournoyer
2023-01-17 16:15 ` Ludovic Courtès
2023-01-15 12:56 ` Akib Azmain Turja
2023-01-15 17:00 ` pelzflorian (Florian Pelz)
2023-01-17 16:25 ` Ludovic Courtès
2023-01-17 23:05 ` zimoun
2023-01-17 23:49 ` zimoun
2023-01-18 21:04 ` Grandfathering store paths considered harmful (was: Packages grow, no longer fit on a 💾) Liliana Marie Prikler
2023-01-19 14:28 ` Grandfathering store paths considered harmful Ludovic Courtès
2023-01-19 18:10 ` Liliana Marie Prikler
2023-01-19 14:14 ` Ludovic Courtès [this message]
2023-01-20 10:51 ` Packages grow, no longer fit on a 💾 Simon Tournier
2023-01-20 14:54 ` Maxim Cournoyer
2023-01-18 2:41 ` kiasoc5
2023-01-18 8:43 ` indieterminacy
2023-01-19 14:32 ` Ludovic Courtès
2023-01-20 11:06 ` Simon Tournier
2023-01-17 8:06 ` Efraim Flashner
2023-01-17 16:18 ` Ludovic Courtès
2023-01-17 21:54 ` John Kehayias
2023-01-19 15:30 ` Katherine Cox-Buday
2023-01-17 15:06 ` Simon Tournier
2023-01-19 14:34 ` Ludovic Courtès
2023-01-18 20:44 ` Paul Jewell via Development of GNU Guix and the GNU System distribution.
2023-01-19 13:04 ` Joshua Branson
2023-01-19 14:37 ` Ludovic Courtès
2023-01-19 16:12 ` Katherine Cox-Buday
2023-01-19 18:07 ` Akib Azmain Turja
2023-01-20 15:30 ` Csepp
2023-01-20 17:34 ` Akib Azmain Turja
2023-01-21 12:29 ` bokr
2023-01-21 15:55 ` Akib Azmain Turja
2023-01-20 12:11 ` Simon Tournier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jsmd31d.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=pelzflorian@pelzflorian.de \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).