guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On the annoyance of multiple outputs


From: Andreas Enge
Subject: On the annoyance of multiple outputs
Date: Mon, 20 Jun 2016 12:27:05 +0200
User-agent: Mutt/1.6.1 (2016-04-27)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]