Re: On the annoyance of multiple outputs

[Ludovic Courtès]

Hello!

Andreas Enge <address@hidden> 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:

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

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’.