From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: [PATCH 3/3] gnu: Add octave and dependencies Date: Sun, 26 Jan 2014 19:54:13 +0100 Message-ID: <20140126185413.GD9380@debian> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7Ur6-0004kx-ID for guix-devel@gnu.org; Sun, 26 Jan 2014 13:54:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7Uqz-0007f5-88 for guix-devel@gnu.org; Sun, 26 Jan 2014 13:54:52 -0500 Content-Disposition: inline In-Reply-To: <20140126073815.GA19985@jocasta.intra> 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 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? Andreas