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

[Andreas Enge <andreas@enge.fr>]

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