bug#58861: guix shell emulate-fhs option can have wrong glibc package

["Ludovic Courtès" <ludo@gnu.org>]

Hi John,

John Kehayias <john.kehayias@protonmail.com> skribis:

> After commit <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652> I noticed a changed in behavior of guix shell with the emulate-fhs option for a container. I tracked it down to the wrong glibc package appearing in the container, i.e. the standard Guix version rather than glibc-for-fhs (which reads a global ld cache).
>
> The cause I believe is related to <https://issues.guix.gnu.org/58859>, namely that package input order for a profile can matter. But it is slightly different here since the glibc-for-fhs package is added internally.
>
> We can see this demonstrated by comparing the FHS container with a -D input so that a glibc package is implicitly included (here from the gnu-build-system):
>
> ❯ guix shell -CFD hello coreutils
> john@narya ~/Files/UPenn/canvasgrading [env]$ ls /lib/ld* -la
> lrwxrwxrwx 1 65534 overflow 69 Jan  1  1970 /lib/ld-2.33.so -> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-2.33.so
> lrwxrwxrwx 1 65534 overflow 79 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2

How about fixing it by moving the (alist-cons 'expression …) thing right
before the ‘options-with-caching’ call in ‘parse-args’?

That way it would no longer be sensitive to the position of ‘-F’ on the
command line.

Could you give it a try and add a test?

Thanks,
Ludo’.