[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On the annoyance of multiple outputs
From: |
Andreas Enge |
Subject: |
Re: On the annoyance of multiple outputs |
Date: |
Sat, 25 Jun 2016 09:43:07 +0200 |
User-agent: |
Mutt/1.6.1 (2016-04-27) |
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