From: Dave Love <fx@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Tiny Guix (and containers)
Date: Tue, 31 Oct 2017 14:17:36 +0000 [thread overview]
Message-ID: <878tfr7667.fsf@albion.it.manchester.ac.uk> (raw)
In-Reply-To: <87r2tn3ulq.fsf@gnu.org> ("Ludovic \=\?iso-8859-1\?Q\?Court\=E8s\?\= \=\?iso-8859-1\?Q\?\=22's\?\= message of "Sat, 28 Oct 2017 22:06:41 +0200")
ludo@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:
>> 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.
I've been arguing for making sub-packages similar to other
distributions, but I'd expect to specify something like :devel as the
input to builds. I'm not sure that it would even work generally to
infer it (e.g. when cross-compiling).
> We could do that (the Nixpkgs folks did exactly that a while back), but
> it won’t help that much.
It looks to me as if it would often help significantly, e.g. when a
pkg-config file, or something else sucks in a load of stuff that's
irrelevant for running the package. (Separating :lib and needing that
for building means you need to know something about the packaging rather
than just using "devel", say.)
> 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.
I think it often will reflect the lack of separation of development
files, documentation, etc., and inclusion of static libraries, for
instance. Boost is a case in point. There's also the issue of multiple
copies/versions of packages in the closure, which seems problematic for
more than just size reasons.
> But yeah, I think we should track packages that are big or have a
> surprisingly build closure, and try to fix that incrementally!
Shouldn't that be done as a matter of course? I don't remember if it's
part of Fedora or Debian packaging guidelines but packagers should check
dependencies for sanity when packaging, and there's some detection of
unnecessary linkage. Guix' Qt dependencies are a striking example which
looks hard to resolve. Generally I get surprised at what typically gets
built -- at great length! -- on updates or installation.
next prev parent reply other threads:[~2017-10-31 14:17 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
2017-10-31 14:17 ` Dave Love [this message]
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=878tfr7667.fsf@albion.it.manchester.ac.uk \
--to=fx@gnu.org \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/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).