all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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

      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.