From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Darrington Subject: Re: [PATCH 3/3] gnu: Add octave and dependencies Date: Mon, 27 Jan 2014 09:30:02 +0100 Message-ID: <20140127083002.GA1813@jocasta.intra> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7haP-00032k-G7 for guix-devel@gnu.org; Mon, 27 Jan 2014 03:30:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7haK-00066i-GW for guix-devel@gnu.org; Mon, 27 Jan 2014 03:30:29 -0500 Content-Disposition: inline In-Reply-To: <877g9mpmmd.fsf@gnu.org> 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: Ludovic Court??s Cc: guix-devel@gnu.org, John Darrington On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote: Andreas Enge skribis: > 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 would be condemned to >> maintain. Further, it seems to me, to be a bit deceptive. By removing makeinfo from >> propagated-inputs we are pretending that makeinfo does not need to 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 be installed with Y. >> >> What benefit does this proposal bring us? > > I think that from a functional point of view, it could be preferable to have > octave "deep link" to its own dependency in the nix store, but I am not sure > if I understand things correctly. > > Assume that octave is compiled with an old version of makeinfo (where "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 installing > octave, it thus pulled the propagated input makeinfo into the user profile. > Now the user installs makeinfo; normally, this should be the new one. > I think right now, there is a warning about a conflict, and then one 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 makeinfo, 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 got 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? Yes, you explained it very well. 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 works 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. With ???propagated-inputs??? here, this would be sort-of achieved, because when installing Octave, the corresponding Texinfo would also get installed. 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. To summarize: ???propagated-inputs??? should list libraries 99% of the 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 this will be. I will do some experiments and see how far I get. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.