Re: [PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote:
     Andreas Enge <address@hidden> 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.