From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 3/3] gnu: Add octave and dependencies Date: Mon, 27 Jan 2014 10:11:14 +0100 Message-ID: <87ha8peqml.fsf@gnu.org> References: <1390507648-21659-1-git-send-email-jmd@gnu.org> <1390507648-21659-3-git-send-email-jmd@gnu.org> <8761p8ulih.fsf@gnu.org> <20140125161456.GA31777@jocasta.intra> <20140125164217.GA21259@debian> <20140125170440.GA4883@jocasta.intra> <871tzvu743.fsf@gnu.org> <20140126073815.GA19985@jocasta.intra> <20140126185413.GD9380@debian> <877g9mpmmd.fsf@gnu.org> <20140127083002.GA1813@jocasta.intra> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7iIp-00035V-C4 for guix-devel@gnu.org; Mon, 27 Jan 2014 04:16:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7iIj-0001yq-Qo for guix-devel@gnu.org; Mon, 27 Jan 2014 04:16:23 -0500 In-Reply-To: <20140127083002.GA1813@jocasta.intra> (John Darrington's message of "Mon, 27 Jan 2014 09:30:02 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: John Darrington Cc: guix-devel@gnu.org, John Darrington John Darrington skribis: > On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote: > Andreas Enge skribis: >=20=20=20=20=20=20 > > On Sun, Jan 26, 2014 at 08:38:16AM +0100, John Darrington wrote: > >> So it would not reduce the total number of "inputs". Further, it= would mean we would have > >> to devise a number of potentially complicated patches, which we w= ould be condemned to > >> maintain. Further, it seems to me, to be a bit deceptive. By re= moving makeinfo from > >> propagated-inputs we are pretending that makeinfo does not need t= o be installed along with > >> octave, whereas in fact, it does (if one wants to read the manual= from within octave). > >> As I understand it, a propagated input means that X must always b= e installed with Y. > >>=20 > >> What benefit does this proposal bring us? > > > > I think that from a functional point of view, it could be preferab= le to have > > octave "deep link" to its own dependency in the nix store, but I a= m not sure > > if I understand things correctly. > > > > Assume that octave is compiled with an old version of makeinfo (wh= ere "old > > version" could simply mean that a dependency of makeinfo has been = updated > > in the mean time, or some of the build tools). At the time of inst= alling > > octave, it thus pulled the propagated input makeinfo into the user= profile. > > Now the user installs makeinfo; normally, this should be the new o= ne. > > I think right now, there is a warning about a conflict, and then o= ne or the > > other takes precedence; I assume the newer one (is this decided on= a file > > by file basis?). So octave has been compiled against an old makein= fo, but > > ends up using a newer one. (Something like this has happened to me= with > > ripperx and cdparanoia; I installed both at different times, and g= ot the > > slightly confusing message that cdparanoia collided with itself). = This seems > > to be a rather annoying "feature" of our propagated inputs, and if= what > > I wrote above is true, they should probably be avoided as much as = possible. > > Ludovic, can you comment? >=20=20=20=20=20=20 > Yes, you explained it very well. >=20=20=20=20=20=20 > The functional model is that anything a package depends on at compile > time, or will depend on at run time, is specified in its definition. > When running ???make && make check???, we check that the package wor= ks > correctly with this particular set of inputs. What we want is that, > when users install the package, it ends up using the inputs that were > specified. >=20=20=20=20=20=20 > With ???propagated-inputs??? here, this would be sort-of achieved, b= ecause > when installing Octave, the corresponding Texinfo would also get > installed. >=20=20=20=20=20=20 > However, that is very inconvenient: what if the user also wants to > install another Texinfo version in their profile? Either the > user-chosen version wins, and Octave may end up working incorrectly;= or > Octave???s version wins, and the user doesn???t have what they asked= for. >=20=20=20=20=20=20 > To summarize: ???propagated-inputs??? should list libraries 99% of t= he > time. Listing programs in ???propagated-inputs??? just for the sake= of > populating $PATH is a bad idea. > > > Ok. Andraes' and Ludo's explanations convince me. However I'm skeptical= that > the Octave devs would be quite so convinced. And removing the propagates= -inputs > will mean patching to the Octave source and I don't know how difficult th= is will be. The patch that would be great upstream is: AC_PATH_PROG([MAKEINFO], [makeinfo]) AC_SUBST([MAKEINFO]) and then use =E2=80=9C@MAKEINFO@=E2=80=9D wherever =E2=80=98makeinfo=E2=80= =99 is expected in the source (similarly for =E2=80=98less=E2=80=99, etc.) The patch that we can do in the meantime is similar to what is done for =E2=80=98glibc=E2=80=99 in base.scm: ;; Have `system' use that Bash. (substitute* "sysdeps/posix/system.c" (("#define[[:blank:]]+SHELL_PATH.*$") (format #f "#define SHELL_PATH \"~a/bin/bash\"\n" out))) ;; Same for `popen'. (substitute* "libio/iopopen.c" (("/bin/sh") (string-append out "/bin/bash"))) HTH, Ludo=E2=80=99.