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

[Ludovic Courtès]

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.

HTH,
Ludo’.