From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: On the annoyance of multiple outputs Date: Mon, 20 Jun 2016 14:46:26 +0200 Message-ID: <877fdk3u59.fsf@gnu.org> References: <20160620102705.GA3648@solar> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEyb3-0000mC-Ba for guix-devel@gnu.org; Mon, 20 Jun 2016 08:46:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEyb0-0005Pp-5S for guix-devel@gnu.org; Mon, 20 Jun 2016 08:46:33 -0400 In-Reply-To: <20160620102705.GA3648@solar> (Andreas Enge's message of "Mon, 20 Jun 2016 12:27:05 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Andreas Enge Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Hello! Andreas Enge 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: --=-=-= Content-Type: text/x-patch Content-Disposition: inline --- 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))) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The 20=C2=A0MiB saved represent 25% of the closure size. To me, it=E2=80= =99s definitely worth it. When I look at the output of =E2=80=98guix size evince=E2=80=99, for instan= ce, I think we should split more, not less (935=C2=A0MiB =E2=80=9Cjust=E2=80=9D for Evi= nce!). Nevertheless, I agree that we should do this when there is a clear justification. In this case, I think there=E2=80=99s a clear justification. Thoughts? Thanks, Ludo=E2=80=99. --=-=-=--