Ludovic Courtès writes: Hello!
> "Zack Weinberg" <[email protected]> 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 <[email protected]> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
