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

[Ludovic Courtès]

Hi John,

John Kehayias  skribis:

> After commit 
> 
>  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 , 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’.

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

[John Kehayias via Bug reports for GNU Guix]

Hi simon and Ludo’,

Before I forget, nckx helpfully pointed out that I linked to the wrong commit, 
which made this all the more confusing. The correct commit is



On Wed, Nov 02, 2022 at 01:47 PM, zimoun wrote:

> Hi,
>
> On sam., 29 oct. 2022 at 05:31, John Kehayias via Bug reports for GNU Guix
>  wrote:
>
>> --8<---cut here---start->8---
>> ❯ guix shell -CFD hello coreutils
>
>> ❯ guix shell -CD hello -F coreutils
>> --8<---cut here---end--->8---
>
> Unrelated, “guix package” provides some ’%actions’ and as reported in
> [1], the command-line order matters – when it should not be.  Maybe, as
> proposed in [1], “guix shell” could process a « plan » with always the
> same order, whatever the command-line order is.
>
> 1: 
>

Thanks, I'll take a look. Seems like we may want to have a more systematic 
method here.

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

[zimoun]

Hi,

On sam., 29 oct. 2022 at 05:31, John Kehayias via Bug reports for GNU Guix 
 wrote:

> --8<---cut here---start->8---
> ❯ guix shell -CFD hello coreutils

> ❯ guix shell -CD hello -F coreutils
> --8<---cut here---end--->8---

Unrelated, “guix package” provides some ’%actions’ and as reported in
[1], the command-line order matters – when it should not be.  Maybe, as
proposed in [1], “guix shell” could process a « plan » with always the
same order, whatever the command-line order is.

1: 


Cheers,
simon

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

[John Kehayias via Bug reports for GNU Guix]

Hi Guixers,

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

After commit 

 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 , 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