Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

  • Open
  • quality assurance status badge
Details
3 participants
  • Janneke Nieuwenhuizen
  • Ludovic Courtès
  • Zack Weinberg
Owner
unassigned
Submitted by
Zack Weinberg
Severity
normal
Z
Z
Zack Weinberg wrote on 7 Jul 2023 14:59
(address . bug-guix@gnu.org)
c33108af-e7b3-4f95-9624-9a702ade8f34@app.fastmail.com
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
L
L
Ludovic Courtès wrote on 15 Aug 2023 23:33
(name . Zack Weinberg)(address . zack@owlfolio.org)(address . 64509@debbugs.gnu.org)
87o7j86ldw.fsf@gnu.org
Hi Zack,

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

Toggle quote (15 lines)
> 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’.
Z
Z
Zack Weinberg wrote on 16 Aug 2023 18:09
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 64509@debbugs.gnu.org)
c66d5270-6a44-4d23-8f5b-830d7f58bbe4@app.fastmail.com
On Tue, Aug 15, 2023, at 5:33 PM, Ludovic Courtès wrote:
Toggle quote (2 lines)
>> The Guile packages currently install all their binaries under their
>> basic name only, e.g.
...
Toggle quote (9 lines)
>> 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
J
J
Janneke Nieuwenhuizen wrote on 21 Aug 2023 09:37
(name . Ludovic Courtès)(address . ludo@gnu.org)
87zg2kj16a.fsf@gnu.org
Ludovic Courtès writes:

Hello!

Toggle quote (17 lines)
> "Zack Weinberg" <zack@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?

Toggle quote (7 lines)
> 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@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Z
Z
Zack Weinberg wrote on 5 Sep 2023 21:59
(address . 64509@debbugs.gnu.org)
2b5e958b-e29b-4147-bedd-520ce1a50aa9@app.fastmail.com
On Mon, Aug 21, 2023, at 3:37 AM, Janneke Nieuwenhuizen wrote:

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (1 lines)
>> I think the solution is to use ‘guix shell -D guix -CP'
...
Toggle quote (1 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 64509@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 64509
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch