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: Sun, 26 Jan 2014 20:30:02 +0100 Message-ID: <877g9mpmmd.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> 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]:52915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7VeK-0000Tr-UA for guix-devel@gnu.org; Sun, 26 Jan 2014 14:45:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7VeE-0006X5-Nt for guix-devel@gnu.org; Sun, 26 Jan 2014 14:45:44 -0500 In-Reply-To: <20140126185413.GD9380@debian> (Andreas Enge's message of "Sun, 26 Jan 2014 19:54:13 +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: Andreas Enge Cc: guix-devel@gnu.org, John Darrington 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 in= stalled along with >> octave, whereas in fact, it does (if one wants to read the manual from w= ithin octave). >> As I understand it, a propagated input means that X must always be insta= lled with Y. >>=20 >> What benefit does this proposal bring us? > > I think that from a functional point of view, it could be preferable to h= ave > octave "deep link" to its own dependency in the nix store, but I am not s= ure > 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 profil= e. > 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 t= he > 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 se= ems > 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 possibl= e. > 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 =E2=80=98make && make check=E2=80=99, we check that the packag= e 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 =E2=80=98propagated-inputs=E2=80=99 here, this would be sort-of achiev= ed, 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=E2=80=99s version wins, and the user doesn=E2=80=99t have what they = asked for. To summarize: =E2=80=98propagated-inputs=E2=80=99 should list libraries 99%= of the time. Listing programs in =E2=80=98propagated-inputs=E2=80=99 just for the= sake of populating $PATH is a bad idea. HTH, Ludo=E2=80=99.