From: ludo@gnu.org (Ludovic Courtès)
To: Hartmut Goebel <h.goebel@crazy-compilers.com>
Cc: guix-devel@gnu.org
Subject: Re: Tiny Guix (and containers)
Date: Sat, 28 Oct 2017 22:06:41 +0200 [thread overview]
Message-ID: <87r2tn3ulq.fsf@gnu.org> (raw)
In-Reply-To: <de6d6cae-1a67-baca-ddc9-e9572af5955b@crazy-compilers.com> (Hartmut Goebel's message of "Fri, 27 Oct 2017 10:25:14 +0200")
Hi,
Hartmut Goebel <h.goebel@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’.
next prev parent reply other threads:[~2017-10-28 20:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-25 8:18 Tiny Guix (and containers) Pjotr Prins
2017-10-25 11:12 ` Pjotr Prins
2017-10-26 7:02 ` Ricardo Wurmus
2017-10-26 10:42 ` Pjotr Prins
2017-10-26 10:48 ` Ricardo Wurmus
2017-10-27 8:25 ` Hartmut Goebel
2017-10-28 20:06 ` Ludovic Courtès [this message]
2017-10-31 14:17 ` Dave Love
2017-11-05 16:02 ` Ludovic Courtès
2017-11-06 15:45 ` Dave Love
2017-11-07 10:19 ` Ludovic Courtès
2017-10-27 0:35 ` Ludovic Courtès
2017-10-31 14:11 ` Dave Love
2017-11-03 12:08 ` Pjotr Prins
2017-11-06 15:10 ` Dave Love
2017-11-05 15:55 ` Ludovic Courtès
2017-11-06 15:11 ` Dave Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2tn3ulq.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=h.goebel@crazy-compilers.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).