--- Begin Message ---
|
Subject: |
guix shell emulate-fhs option can have wrong glibc package |
|
Date: |
Sat, 29 Oct 2022 05:31:05 +0000 |
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [PATCH] shell: Fix '--emulate-fhs' sometimes not including 'glibc-for-fhs'. |
|
Date: |
Sun, 06 Nov 2022 12:18:28 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
Hi,
John Kehayias <john.kehayias@protonmail.com> skribis:
> From 72be4a15a10916ae8d51dfb2998d6179bc57be59 Mon Sep 17 00:00:00 2001
> From: John Kehayias <john.kehayias@protonmail.com>
> Date: Thu, 3 Nov 2022 14:25:09 -0400
> Subject: [PATCH] shell: Fix '--emulate-fhs' sometimes not including
> 'glibc-for-fhs'.
>
> Fixes <https://issues.guix.gnu.org/58861>.
>
> Previously the order of the options giving to 'guix shell' could mean that the
> 'glibc-for-fhs' package included with the '--emulate-fhs' option would not
> appear in the container. For example, using the development option with a
> package using the 'gnu-build-system', e.g. 'guix shell -CFD hello', would
> include the regular 'glibc' package. The option ordered mattered: 'guix shell
> -CD hello -F' would include the expected 'glibc-for-fhs'. We fix this by
> having 'glibc-for-fhs' added to the package list just before calling
> 'options-with-caching' so the option order given by the user does not matter.
>
> * guix/scripts/shell.scm (%options): Move the '--emulate-fhs' (expression
> . ...) component from here...
> (parse-args): ... to here.
> * tests/guix-environment-container.sh: Add a test to check that
> 'glibc-for-fhs' is in the container even when 'glibc' is included in the 'guix
> shell' package list.
Perfect; applied, thanks!
Ludo’.
--- End Message ---