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

[Ludovic Courtès]

John Darrington <address@hidden> skribis:

> 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.

The patch that would be great upstream is:

  AC_PATH_PROG([MAKEINFO], [makeinfo])
  AC_SUBST([MAKEINFO])

and then use address@hidden@” wherever ‘makeinfo’ is expected in the source
(similarly for ‘less’, etc.)

The patch that we can do in the meantime is similar to what is done for
‘glibc’ in base.scm:

  ;; Have `system' use that Bash.
  (substitute* "sysdeps/posix/system.c"
    (("#define[[:blank:]]+SHELL_PATH.*$")
     (format #f "#define SHELL_PATH \"~a/bin/bash\"\n"
             out)))

  ;; Same for `popen'.
  (substitute* "libio/iopopen.c"
    (("/bin/sh")
     (string-append out "/bin/bash")))

HTH,
Ludo’.