Re: Tiny Guix (and containers)

[Ludovic Courtès]

Hi,

Hartmut Goebel <address@hidden> skribis:

> Am 26.10.2017 um 12:42 schrieb Pjotr Prins:
>> Yes, I think that is what we should head for eventually. I vaguely
>> remember a discussion about this on this ML and people were against
>> separate outputs for doc, include, static-lib etc.  What are you all
>> thinking now? Does it make sense to have the base package as small as
>> possible and split out the rest?
>
> I'm in favor of (automatically?) splitting of "development" packages,
> including the headers and the static libs (much like the "-devel" or
> "-dev" packages in other distributions. One does not need them on a
> production system and they are just wasting space. When Guix needs to
> build a package, it automatically installs the ":devel" output of all
> it's inputs.

We could do that (the Nixpkgs folks did exactly that a while back), but
it won’t help that much.  What does help is running ‘guix size’, looking
at specific packages that are problematic, then finding a solution for
these packages—and often enough the solution is non-trivial.

But yeah, I think we should track packages that are big or have a
surprisingly build closure, and try to fix that incrementally!

> Regarding localization-files I'm unsure if for the average package this
> is worth the effort. But for big packages this could be worth the
> effort. Maybe we could even make them "noarch" packages, thus savine
> space and build time.

For things like Binutils, libc, or LO, it surely makes a difference.

For an FHS distro it’s easy to keep locale data separate.  In our case,
I’m not sure how to do it, as discussed earlier.

Thanks,
Ludo’.