Re: Tiny Guix (and containers)

[Hartmut Goebel <h.goebel@crazy-compilers.com>]

Hello,

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 the same for "docs", but "docs" may not be easy to
determine, except for man-pages and info-files.

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.

Here is a list of "langpacks" my distribution offers (I used pt_BR since
this is easy to search in the package-repo):
aspell-pt_BR
childsplay-sounds-pt_BR
firefox-pt_BR
gcompris-sounds-pt_BR
gnome-getting-started-docs-pt_BR
kde-l10n-handbooks-pt_BR
kde-l10n-pt_BR
kompozer-myspell-pt_BR
kompozer-pt_BR
libreoffice-langpack-pt_BR
man-pages-pt_BR
thunderbird-pt_BR

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |