GNU bug report logs - #64509
Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

Previous Next

To reply to this bug, email your comments to 64509 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: bug-guix <at> gnu.org
Subject: Guile packages should install versioned aliases for binaries
 (guile-X.Y, guild-X.Y, etc.)
Date: Fri, 07 Jul 2023 08:59:10 -0400

The Guile packages currently install all their binaries under their
basic name only, e.g.

$ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
/gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
guild  guile  guile-config  guile-snarf  guile-tools

However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
If it finds one, then it looks *only* for a matching guild-X.Y and
errors out if it can’t find that.  This is a problem for building Guix
itself from source in a non-pure ‘guix shell -D guix’ on top of a
foreign distro that provides a ‘guile-3.0’ binary but not the other
four programs:

$ which guile || echo not found
/gnu/store/1yg0gg12m2cj2lj08r3qx8yx6zir4a38-profile/bin/guile

$ which guile-3.0 || echo not found
/usr/bin/guile-3.0

$ which guild || echo not found
/gnu/store/1yg0gg12m2cj2lj08r3qx8yx6zir4a38-profile/bin/guild

$ which guild-3.0 || echo not found
not found

$ ./configure --localstatedir=/var
...
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 3.0
configure: found guile 3.0
checking for guile-3.0... /usr/bin/guile-3.0
checking for Guile version >= 3.0... 3.0.8
checking for guild-3.0... no
checking for guile-config-3.0... no
checking for guile-tools-3.0... no
configure: error: 'guild' binary not found; please check your Guile installation.

Thus, I suggest that all of the Guix guile packages should be modified
to install ‘guile-X.Y’, ‘guild-X.Y’, etc. as well as the unsuffixed
program names.  I do not immediately see how to make this change in
gnu/packages/guile.scm.

zw

Message #8 received at 64509 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: "Zack Weinberg" <zack <at> owlfolio.org>
Cc: 64509 <at> debbugs.gnu.org
Subject: Re: bug#64509: Guile packages should install versioned aliases for
 binaries (guile-X.Y, guild-X.Y, etc.)
Date: Tue, 15 Aug 2023 23:33:47 +0200

Hi Zack,

"Zack Weinberg" <zack <at> owlfolio.org> skribis:

> The Guile packages currently install all their binaries under their
> basic name only, e.g.
>
> $ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
> /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
> guild  guile  guile-config  guile-snarf  guile-tools
>
> However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
> for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
> If it finds one, then it looks *only* for a matching guild-X.Y and
> errors out if it can’t find that.  This is a problem for building Guix
> itself from source in a non-pure ‘guix shell -D guix’ on top of a
> foreign distro that provides a ‘guile-3.0’ binary but not the other
> four programs:

I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
you a container, where /usr/bin/guile-3.0 isn’t accessible, which
ensures there’s no interference.

(FWIW this is what I do, even on Guix System, for my development
environments.)

Does that work for you?

If your distro doesn’t support unprivileged user namespaces, which ‘-C’
relies on, you can fall back to ‘--pure’.

Ludo’.

Message #11 received at 64509 <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 64509 <at> debbugs.gnu.org
Subject: Re: bug#64509: Guile packages should install versioned aliases for
 binaries (guile-X.Y, guild-X.Y, etc.)
Date: Wed, 16 Aug 2023 12:09:21 -0400

On Tue, Aug 15, 2023, at 5:33 PM, Ludovic Courtès wrote:
>> The Guile packages currently install all their binaries under their
>> basic name only, e.g.
...
>> This is a problem for building Guix
>> itself from source in a non-pure ‘guix shell -D guix’ on top of a
>> foreign distro that provides a ‘guile-3.0’ binary but not the other
>> four programs:
>
> I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
> you a container, where /usr/bin/guile-3.0 isn’t accessible, which
> ensures there’s no interference.

I can't use container mode (or pure mode), because there's another
layer in the way: I'm using <https://github.com/purcell/envrc> to
pull settings out of `guix shell` and poke them into Emacs.  This
inherently only supports non-pure operation.

zw

Message #14 received at 64509 <at> debbugs.gnu.org (full text, mbox):

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 64509 <at> debbugs.gnu.org, Zack Weinberg <zack <at> owlfolio.org>
Subject: Re: bug#64509: Guile packages should install versioned aliases for
 binaries (guile-X.Y, guild-X.Y, etc.)
Date: Mon, 21 Aug 2023 09:37:49 +0200

Ludovic Courtès writes:

Hello!

> "Zack Weinberg" <zack <at> owlfolio.org> skribis:
>
>> The Guile packages currently install all their binaries under their
>> basic name only, e.g.
>>
>> $ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
>> /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
>> guild  guile  guile-config  guile-snarf  guile-tools
>>
>> However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
>> for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
>> If it finds one, then it looks *only* for a matching guild-X.Y and
>> errors out if it can’t find that.  This is a problem for building Guix
>> itself from source in a non-pure ‘guix shell -D guix’ on top of a
>> foreign distro that provides a ‘guile-3.0’ binary but not the other
>> four programs:

It's an interesting idea.  It's a common source of problems for non-guix
system users.  It's terrible that guile.m4 has this feature of
preferring numbered binaries (even if they're later in PATH, and even if
that binary doesn't match GUILE_LOAD_*PATHs), and that Guix doesn't
provide them.

What about a wrapper package that provides these?

> I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
> you a container, where /usr/bin/guile-3.0 isn’t accessible, which
> ensures there’s no interference.
>
> (FWIW this is what I do, even on Guix System, for my development
> environments.)

Hmm, yeah -- that sounds like the proper way of doing things.  Maybe my
pracice and advise should go into that direction instead.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Message #17 received at 64509 <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: "Janneke Nieuwenhuizen" <janneke <at> gnu.org>,
 Ludovic Courtès <ludo <at> gnu.org>
Cc: 64509 <at> debbugs.gnu.org
Subject: Re: bug#64509: Guile packages should install versioned aliases for
 binaries (guile-X.Y, guild-X.Y, etc.)
Date: Tue, 05 Sep 2023 15:59:21 -0400

On Mon, Aug 21, 2023, at 3:37 AM, Janneke Nieuwenhuizen wrote:

> It's terrible that guile.m4 has this feature of preferring numbered
> binaries (even if they're later in PATH, and even if that binary
> doesn't match GUILE_LOAD_*PATHs)

I can see why it does this -- it wants to find the newest available
Guile and it wants to be sure that all the binaries it uses are a
matched set. The original design assumption was probably that, if you're
using numbered binaries, then the un-suffixed "guile" can't be relied on
to be the newest available.  (Not as strange as it might sound; I have a
login on a machine where un-suffixed "perl" still runs Perl 5.005_02,
because the admins want to make absolutely sure that they never break
any user's #! scripts.)

It would probably be a good idea for guile.m4 to be altered to take the
un-suffixed binaries if that's the only way it can get a full set, but
given how long it takes for Autoconf macro changes to propagate to the
world, I think Guix should provide the numbered binaries regardless.

> and that Guix doesn't provide them. What about a wrapper package that
> provides these?

Why bother with a wrapper?  It should be _easier_ to have the main guile
package supply the numbered binaries.

>> I think the solution is to use ‘guix shell -D guix -CP'
...
> Hmm, yeah -- that sounds like the proper way of doing things
...

Not an option for me, for reasons explained in my earlier reply to
Ludovic.

zw

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.