Hi, On Mon, 08 Dec 2025 at 15:27, Ludovic Courtès <[email protected]> wrote:
>> Then, package size: ‘emacs-calibredb’ is 5 GB. This is not an >> exception, but rather the norm, I’m afraid. > > Oh yes. This has been bothering me forever :-) and that’s why ‘guix > size’ has existed almost since day 1, with contribution guidelines > telling users to pay attention to that (info "(guix) Submitting > Patches"). > > But clearly, this hasn’t really worked, and here we are today. > > Maybe one thing we can do is to organize an on-line hackathon where we’d > team up to focus specifically on this issue for one or two days? > There’s already a call for action in > <https://codeberg.org/guix/guix/issues/938#issuecomment-8593863> that > could be used as a starting point. > > If someone organizes this before soon enough, we could even report back > during the Guix Days. The output of this hackathon could be helpful in the very short term – some weeks at best – but not on a longer term where we’ll have again and again the same discussion. I remember past discussions back on 2020 with Pierre and others on “Reducing closure size”. [1] Look, this message [2] from 2020 reported: $ guix size llvm store item total self /gnu/store/…-llvm-10.0.0 210.8 139.3 66.1% /gnu/store/…-glibc-2.31 38.4 36.7 17.4% /gnu/store/…-gcc-7.5.0-lib 71.0 32.6 15.5% /gnu/store/…-bash-static-5.0.16 1.6 1.6 0.8% /gnu/store/…-zlib-1.2.11 71.2 0.2 0.1% /gnu/store/…-libffi-3.3 71.2 0.2 0.1% total: 210.8 MiB And Pierre tried hard to reduce this closure (among many others). I don’t remember if this reduction has been achieved or not at the time. For sure, today, it’s a failure! $ guix size llvm store item total self /gnu/store/fnyink8jx3acd63h2l63by7jp9cra3pv-llvm-21.1.5 681.1 606.5 89.1% /gnu/store/yj053cys0724p7vs9kir808x7fivz17m-glibc-2.41 41.0 39.2 5.8% /gnu/store/m2vhzr0dy352cn59sgcklcaykprrr4j6-gcc-14.3.0-lib 74.1 33.1 4.9% /gnu/store/98rxpjki5i0ri1n3w7nwf1j4x9qxl2xl-bash-static-5.2.37 1.8 1.8 0.3% /gnu/store/a2jnc1avp7jdyp01r9kpp8q1i72kk8g0-zlib-1.3.1 74.4 0.2 0.0% /gnu/store/qvp9pb46k3qnpgb6sx7cjzfpcrkkqgnp-libffi-3.4.6 74.3 0.2 0.0% total: 681.1 MiB Look this message [3] reported on 2020 “guix size emacs” about “total: 859.7 MiB” and today it’s about “total: 2159.9 MiB”. And so on, and so on. After these efforts on 2020 and then seeing they are kind of worthless, my personal conclusion on this topic is: 1. Without a strong policy on package addition and upgrade, any action against closure size will have no impact. 2. Once added, it’s very hard, near to impossible, to then remove. Somehow, chasing closure bytes package per package is a “loose of time“, IMHO, because next week or next month, we will have one package upgrade that defeats all the effort. The only way to make the chase worth is to guard by encoding a collective rule on the closure size. *loose of time: Do not take me wrong: Diving into the arcane of one package is never a loose of time! For sure, we have technical annoyances^W bugs and fixing them would be super helpful! In addition to Ludo’s reference [4], see [5] about grafts and downloading ’-debug’ output. Somehow, the main issue about closure size isn’t some technical issues but a collective decision, IMHO. Cheers, simon 1: Guix size reduction work group Pierre Neidhardt <[email protected]> Tue, 04 Feb 2020 16:57:17 +0100 id:[email protected] https://lists.gnu.org/archive/html/guix-devel/2020-02 https://yhetil.org/guix/[email protected] 2: Reducing LLVM closure size Pierre Neidhardt <[email protected]> Fri, 12 Jun 2020 11:06:32 +0200 id:[email protected] https://lists.gnu.org/archive/html/guix-devel/2020-06 https://yhetil.org/guix/[email protected] 3: Emacs closure at ~900MB? zimoun <[email protected]> Tue, 22 Sep 2020 13:16:44 +0200 id:[email protected] https://lists.gnu.org/archive/html/guix-devel/2020-09 https://yhetil.org/guix/[email protected] 4: https://codeberg.org/guix/guix/issues/938 5: https://codeberg.org/guix/guix/issues/3617
