Patchwork On the annoyance of multiple outputs

login
register
mail settings
Submitter Ludovic Courtès
Date June 20, 2016, 12:46 p.m.
Message ID <877fdk3u59.fsf@gnu.org>
Download mbox | patch
Permalink /patch/13230/
State New
Headers show

Comments

Ludovic Courtès - June 20, 2016, 12:46 p.m.
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:
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’.
Andreas Enge - June 25, 2016, 7:43 a.m.
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

Patch

--- 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)))