On Thu, 11 Dec 2025 12:15:03 +0100 Andreas Enge <[email protected]> wrote:
> > Would it be feasible and desirable to have a “sober” version and a
> > “complete” version for certain packages? In terms of compilation
> > options, inclusion of documentation, debug sections, etc => fewer
> > inputs.
>
> It is not clear that this would always be a good idea. Of some
> packages we have regular and minimal versions (for instance, minimal
> is needed to bootstrap the full version; or minimal is enough as a
> native input for building other packages).
I think it really depends on what is the real goal here. Having real
uses cases makes sure that what we do is useful.
For instance having a console-only Emacs (emacs-no-x) makes sense as we
don't have to pull a lot of dependencies, and this is used for real
(for instance I use it on my server, and it's safe to say that I'm
hardly the only one).
It could also be useful to optimize certain packages to fit some use
cases. For instance several ARM computers have 4GiB eMMC (Beaglebone
Green, lime2-emmc), so having everything fit is desirable for many
different reasons (reliability, speed, etc). So this means that there
is also a real incentive to make sure it continues to fit.
The problem of space is also what prevent many uses cases of Guix, like
the use in embedded devices (devices with specific use cases that
often have some constraint like limited space) so it's worth trying to
find ways to make things better.
The issue is that it's not simple. There are ways to have huge space
gains, for instance projects like Yocto/Openembedded and the
distributions that use it typically split packages much more than what
general purpose distributions do. Manuals end up in separate packages,
etc.
The biggest part of it is done at the distribution level and not at the
packaging level: this is done automatically (you do nothing and manuals
will end up in a -doc package, because they are installed in
${prefix}/share/man).
The problem is that I'm unsure how that could fit within Guix, as
distributions based on Yocto/Openembedded are not really general
purpose.
There were also lot of discussions in Guix about all that in the past
and we still have not managed to find a way to do that distribution
wide (because this is something complicated to do).
My guess is that doing that kind of split has huge costs both in
usability and in increase of time for packaging (the later could be
acceptable though).
A example here would be how to keep things reproducible, have manuals
installed automatically for regular usage, but not for embedded usage,
without having to rebuild everything just to have a Guix version with
split packages.
Maybe a way out of this mess would be to somehow have generic functions
that take into input a package and that outputs a new split package,
without rebuilding anything.
If we go further we could also write functions that take a system
definition as input outputs a new system definition with only the new
split packages, and without any manuals, to get smaller images, and
another one to generate a tarball with only all the manuals (to be
viewed on a host computer).
This would also enable people to test things with these, to see how
usable it is, etc.
Note that I've no idea if build time vs run time dependencies
optimizations could still yield some space gains on some targets (I've
no idea if this was already looked at, done, or if it's still left to
do) but that could also be something to look into if there is still
some room for improvements.
Here are more examples of real use cases:
- Guix doesn't support ARMv6, but if it did a use case would be to fit
in the Aspeed BMCs (available in the Talos II for instance).
On the Talos they have limited space (32 MiB). They probably have even
less on the KGPE-D16. Note that I don't have a Talos nor an Aspeed
BMC so I can't help here.
So the idea here would be to have OpenWRT level space optimizations
(use a tiny busybox built with a custom config, use dropbear instead
of OpenSSH, use sstrip instead of strip, split the packages,
maybe don't use shepherd but use procd, or find some tiny scheme
implementation to run the init scripts, etc).
- Even with bigger ARM computers, the eMMC sizes are quite limited. You
have sizes like 128 GiB maximum (rockpro64, rock-4c-plus) and these
aren't cheap, so this can create a lot of incentive to keep the space
consumption low.
Denis.
pgpWhQTP0td3Y.pgp
Description: OpenPGP digital signature
