From: ludo@gnu.org (Ludovic Courtès)
To: John Darrington <john@darrington.wattle.id.au>
Cc: guix-devel@gnu.org, John Darrington <jmd@gnu.org>
Subject: Re: [PATCH 3/3] gnu: Add octave and dependencies
Date: Mon, 27 Jan 2014 10:11:14 +0100 [thread overview]
Message-ID: <87ha8peqml.fsf@gnu.org> (raw)
In-Reply-To: <20140127083002.GA1813@jocasta.intra> (John Darrington's message of "Mon, 27 Jan 2014 09:30:02 +0100")
John Darrington <john@darrington.wattle.id.au> skribis:
> On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote:
> Andreas Enge <andreas@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’.
next prev parent reply other threads:[~2014-01-27 9:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-23 20:07 [PATCH 1/3] gnu: libxft: Propagate input John Darrington
2014-01-23 20:07 ` [PATCH 2/3] gnu: fltk: New module John Darrington
2014-01-24 16:07 ` Thompson, David
2014-01-25 7:00 ` [PATCH 2/2] " John Darrington
2014-01-25 8:27 ` (unknown), John Darrington
2014-01-25 8:27 ` [PATCH] gnu: fltk: New module John Darrington
2014-01-25 15:39 ` Ludovic Courtès
2014-01-23 20:07 ` [PATCH 3/3] gnu: Add octave and dependencies John Darrington
2014-01-25 15:30 ` Ludovic Courtès
2014-01-25 16:14 ` John Darrington
2014-01-25 16:42 ` Andreas Enge
2014-01-25 17:04 ` John Darrington
2014-01-25 20:41 ` Ludovic Courtès
2014-01-26 7:38 ` John Darrington
2014-01-26 9:09 ` (unknown), John Darrington
2014-01-26 9:09 ` [PATCH] gnu: Add gnuplot John Darrington
2014-01-26 20:17 ` Ludovic Courtès
2014-01-26 18:54 ` [PATCH 3/3] gnu: Add octave and dependencies Andreas Enge
2014-01-26 19:30 ` Ludovic Courtès
2014-01-27 8:30 ` John Darrington
2014-01-27 9:11 ` Ludovic Courtès [this message]
2014-01-29 8:20 ` John Darrington
2014-01-29 21:26 ` Ludovic Courtès
2014-01-27 9:04 ` Sree Harsha Totakura
2014-01-27 9:53 ` Installing a C tool chain Ludovic Courtès
2014-01-27 10:32 ` Sree Harsha Totakura
2014-02-04 6:31 ` Mark H Weaver
2014-04-05 20:44 ` Ludovic Courtès
2014-04-14 17:54 ` Andreas Enge
2014-04-14 19:16 ` Ludovic Courtès
2014-04-14 19:43 ` Andreas Enge
2014-04-14 21:32 ` Ludovic Courtès
2014-04-14 21:57 ` Sergio Durigan Junior
2014-01-24 13:11 ` [PATCH 1/3] gnu: libxft: Propagate input Ludovic Courtès
2014-01-25 7:01 ` [PATCH 1/2] " John Darrington
2014-01-25 15:19 ` Ludovic Courtès
2014-01-25 15:38 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ha8peqml.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=jmd@gnu.org \
--cc=john@darrington.wattle.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).