From: Andreas Enge <andreas@enge.fr>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: On the annoyance of multiple outputs
Date: Sat, 25 Jun 2016 09:43:07 +0200 [thread overview]
Message-ID: <20160625074307.GA1540@solar> (raw)
In-Reply-To: <877fdk3u59.fsf@gnu.org>
On Mon, Jun 20, 2016 at 02:46:26PM +0200, Ludovic Courtès wrote:
> I would suggest instead fixing the remaining issues, which is going to
> be way faster than rebuilding everything.
Thanks for beating me to it, I was about to have a look :-)
> - (outputs '("out"
> - "doc")) ;1.8 MiB of HTML
> + (outputs '("out" ;library & headers
> + "bin" ;depends on Readline (adds 20MiB to the closure)
> + "doc")) ;1.8 MiB of HTML
> (inputs `(("bzip2" ,bzip2)
> ("readline" ,readline)
> ("zlib" ,zlib)))
> The 20 MiB saved represent 25% of the closure size. To me, it’s
> definitely worth it.
This is of course a question of taste now; even on my computationally weak
machines, I have enough disk space to not bother. My argument was to not look
at the relative size, but the absolute savings; 20MB is nothing I would worry
about. And moreover I suppose that readline is installed more or less every-
where. So what would count is not the closure size of an individual package,
but of a profile as a whole; and this is of course not an objective measure
any more.
> When I look at the output of ‘guix size evince’, for instance, I think
> we should split more, not less (935 MiB “just” for Evince!).
Skimming over the output, big chunks of this are gtk+, python and mesa, for
instance. I suppose that someone wanting to install evince has all of them
anyway. More surprising is the reference to gcc.
When splitting a package, I would not consider the closure size, but only
(except for special cases) the size of the package itself.
Andreas
prev parent reply other threads:[~2016-06-25 7:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 10:27 On the annoyance of multiple outputs Andreas Enge
2016-06-20 12:46 ` Ludovic Courtès
2016-06-25 7:43 ` Andreas Enge [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160625074307.GA1540@solar \
--to=andreas@enge.fr \
--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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.