[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On the annoyance of multiple outputs
From: |
Ludovic Courtès |
Subject: |
Re: On the annoyance of multiple outputs |
Date: |
Mon, 20 Jun 2016 14:46:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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’.