John Darrington <j...@darrington.wattle.id.au> skribis:
> On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote:
> Andreas Enge <andr...@enge.fr> 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 “@MAKEINFO@” 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’.
