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

[John Kehayias]

Hi Guixers,

(cc'ing Ludo’ as author of the commit referenced below)

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):

--8<---------------cut here---------------start------------->8---
❯ 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
--8<---------------cut here---------------end--------------->8---

Note that the loader comes from the standard glibc package. This means it won't 
read from the global cache.

However, if we change the order, placing the FHS option after the (implicit) 
glibc input, we do get the glibc-for-fhs package. This is similar to #58859 
which I just reported:

--8<---------------cut here---------------start------------->8---
❯ guix shell -CD hello -F coreutils
The following derivation will be built:
  /gnu/store/1hvdkgp68nak827qx6vhmrixdixnl6yl-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building profile with 23 packages...

[env]$ ls /lib/ld* -la
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2
--8<---------------cut here---------------end--------------->8---

Here the ld loader is as it should be for the FHS container.

This was not the behavior before 8b192c5550213911f930594f4fd7386f36618237, 
where the option handling was moved to shell rather than environment for 
emulate-fhs. Reverting this commit and doing the same thing, I get

--8<---------------cut here---------------start------------->8---
❯ ./pre-inst-env guix shell -CFD hello coreutils

[env]$ ls -la /lib/ld*
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2

[env]$ exit

❯ ./pre-inst-env guix shell -CD hello -F coreutils

[env]$ ls -la /lib/ld*
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2
--8<---------------cut here---------------end--------------->8---

Both cases have the expected behavior. The glibc-for-fhs package being added to 
the profile is done last, when creating the manifest, so I think it is the last 
package in the list and thus "wins out" over the glibc from the --development 
input (in keeping with the behavior noted in #58859).

Further, I don't reproduce the bug that the commit above was supposed to fix: 
running the same FHS container shell multiple times (so the profile is cached) 
does not give me any errors. Although I didn't test for this specifically 
before the final FHS patches, I did (and do) use the same cached profiles 
repeatedly.

Was the bug in using the --profile option in combination with --emulate-fhs? I 
haven't tested that, but I could see that being the problem instead.

Assuming there is a problem with profiles and emulate-fhs, what is the best fix 
here? My guess is to put the glibc-for-fhs package always last to make sure it 
is the glibc of the profile in this case to always have the same (expected) 
behavior.

Thanks!
John