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
?