On the annoyance of multiple outputs

On the annoyance of multiple outputs

[Andreas Enge]

Hello,

commit 6d49ca3bad613700b539c30272e164207455735b in core-updates has added a
"bin" output to pcre. This broke the build of swig (corrected later by
Ludovic), and it also broke at least the build of 4store. I suggest to revert
the first commit.

Notice that the bin output contains only the following:
-r-xr-xr-x 2 root root   2465  1. Jan 1970  pcre-config
-r-xr-xr-x 2 root root 101344  1. Jan 1970  pcregrep
-r-xr-xr-x 2 root root 105016  1. Jan 1970  pcretest
Apparently pcre-config is used routinely for checking if pcre is available.
So the additional output saves little and causes a lot of hassle.

I would like to take the opportunity to iterate my skepticism as to the
splitting of packages into several outputs. This follows the slippery slope
of the Debian style with a regular package and an additional "-dev" package,
where by installing just one package (that is, the "out" output), one does
not get all of its functionality. This is also surprising and wastes a lot
of peoplepower (when seeing the build failure of swig, I did not even guess
it could be related to an incomplete pcre package).

So in fact, I suggest to unite all of the outputs of pcre into one; the "doc"
output is also relatively small:
1792	/gnu/store/c6lrgvva6vzly6ni7f8al9qsdw88hjrf-pcre-8.38-doc
216	/gnu/store/10xwfx7yvbd1mbgm5c78nh1h3sf3l95y-pcre-8.38-bin
3628	/gnu/store/zwc6ck9j0wv80kz5snw5acwb39ws88m1-pcre-8.38
Granted, the doc output takes about a third of the complete package size,
but it is still quite moderate absolutely.

In my opinion, splitting into several outputs should be limited to cases
where the difference is massive (qt-4 being a good example, where the "doc"
output contains 277 MB).

What do you think?

Andreas

Re: On the annoyance of multiple outputs

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

Hello!

Andreas Enge <andreas@enge.fr> skribis:

> commit 6d49ca3bad613700b539c30272e164207455735b in core-updates has added a
> "bin" output to pcre. This broke the build of swig (corrected later by
> Ludovic), and it also broke at least the build of 4store. I suggest to revert
> the first commit.

I would suggest instead fixing the remaining issues, which is going to
be way faster than rebuilding everything.

> I would like to take the opportunity to iterate my skepticism as to the
> splitting of packages into several outputs. This follows the slippery slope
> of the Debian style with a regular package and an additional "-dev" package,
> where by installing just one package (that is, the "out" output), one does
> not get all of its functionality. This is also surprising and wastes a lot
> of peoplepower (when seeing the build failure of swig, I did not even guess
> it could be related to an incomplete pcre package).
>
> So in fact, I suggest to unite all of the outputs of pcre into one; the "doc"
> output is also relatively small:
> 1792	/gnu/store/c6lrgvva6vzly6ni7f8al9qsdw88hjrf-pcre-8.38-doc
> 216	/gnu/store/10xwfx7yvbd1mbgm5c78nh1h3sf3l95y-pcre-8.38-bin
> 3628	/gnu/store/zwc6ck9j0wv80kz5snw5acwb39ws88m1-pcre-8.38
> Granted, the doc output takes about a third of the complete package size,
> but it is still quite moderate absolutely.
>
> In my opinion, splitting into several outputs should be limited to cases
> where the difference is massive (qt-4 being a good example, where the "doc"
> output contains 277 MB).
>
> What do you think?

I think we definitely need to pay attention to big packages like Qt, but
we also need to pay attention to packages that are smaller but have a
lot of users.

In the case of PCRE (900+ dependent packages), commit
6d49ca3bad613700b539c30272e164207455735b gives the rationale:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 622 bytes --]

--- a/gnu/packages/pcre.scm
+++ b/gnu/packages/pcre.scm
@@ -45,8 +45,9 @@
               "1pvra19ljkr5ky35y2iywjnsckrs9ch2anrf5b0dc91hw8v2vq5r"))
             (patches (list (search-patch "pcre-CVE-2016-3191.patch")))))
    (build-system gnu-build-system)
-   (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)))

[-- Attachment #3: Type: text/plain, Size: 412 bytes --]


The 20 MiB saved represent 25% of the closure size.  To me, it’s
definitely worth it.

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!).
Nevertheless, I agree that we should do this when there is a clear
justification.  In this case, I think there’s a clear justification.

Thoughts?

Thanks,
Ludo’.

Re: On the annoyance of multiple outputs

[Andreas Enge]

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