Re: Packages grow, no longer fit on a 💾

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

> Yeah for sure. :-) Although, from my point of view, the main issue is
> about a policy for package inclusion; I mean there is no secret: light
> images means images with less features. :-)
>
> My personal and biased opinion is that Guix should follow minimalist
> packages as default packages and provides more variants.  But the
> maintenance cost is not free, IMHO. :-)

My personal take on this would be to start with fixing *bugs* like
#25235 (Wrapped python programs get native-inputs in PYTHONPATH) that
surely contributes to larger graphs, pulling purely build time
dependencies in the graph (there's a fix proposed in the same thread).
This one is for Python, but the same must apply to other scripting
languages that rely on wrap phases.  The pulling of large debug outputs
just to graft locally is also annoying, but that wouldn't end up in the
image produced, right?

I don't think deduplication is turned on for all the images produced by
guix pack such as Docker, which would mean grafts have a heavy cost
there.

Other idea: move the static libraries detected to a static output
automatically when a "static" output is declared, else remove them, in
the gnu-build-system standard phases.

While I agree we can do better, in general I don't think we can compete
with Alpine, which appears to aim for minimalism at the expense of
features.  I don't think GNU Guix is about that kind of minimalism; it
aims to empower its users through full-featured and well documented
packages.  I also think it's nice to ship at least the info/man pages
documentation in the main output in general, even if it makes our
packages slightly larger than on Alpine, and stripping include files in
a different output seems a pain to deal with, from a user perspective.

I guess what I'm saying is that there seems to be larger and lower
hanging fruits to collect before we start micro-managing package
outputs.

-- 
Thanks,
Maxim