Hi, Hartmut Goebel <h.goe...@crazy-compilers.com> 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’.
