Ive been trying to package Scryer-Prolog.
Beyond the tradeoffs from its Rust underbelly and the volume of
dependencies,
Ive been taking the position of packaging everything (including all
those random tests the package developers had decided upon) - a rather
ugly experience.
The hope is that I can present enough aspects, including the dependency
chains in a form that community understands - which for them can be in
Prolog.
Im hoping that the time investment at my end can result in them having
granularity commensurate with their needs and encourage a conversation
which they can resolve efficiently.
The approach I took was to heavily break things down into modules rather
than larger themes that Guixs repo policy provides.
From my perspective satisfying granularity has been tough but hopefully
their particular needs for reproducability and bespoke packaging
flavours will result in more sustainable outcomes.
Kind regards,
Jonathan
On 2025-12-19 12:10, Simon Tournier wrote:
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
