[bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option.

[Ludovic Courtès]

Howdy,

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

>> I would prefer to keep complexity as low as possible, and thus not have
>> this glibc variant.
>> 
>> Now, I don’t know for this use case how much it matters that libc honors
>> /etc/ld.so.cache. Intuitively, like I wrote on guix-devel, I’d think
>> ld.so.cache doesn’t matter, but you encountered counterexamples.
>> 
>> So I guess that if in practice presence of /etc/ld.so.cache and having
>> glibc honor it is necessary often enough, we can do that.
>> 
>
> Right, though as I said, happy to hear of alternatives or what other use 
> cases come up. This seems rather robust to any "usual" assumptions though.
>
>> It seems that ‘glibc-for-fhs’ is merely added to the environment though,
>> and not actually used?
>> 
>
> Well, it is added to the environment which here means the glibc-for-fhs lib 
> directory ends up in the container's global /lib. This may be useful for 
> anything expecting a more "typical" glibc to be found in the typical 
> location. I can't say I know the particulars here, other than binaries and an 
> example of other nested containers (used in non-free software, but the 
> containers are bwrap and friends) expecting glibc to default to a global ld 
> cache. Again, there may be other workarounds or ways to reduce this, but for 
> now I followed the "emulate" part of the flag :)

Oh I got it; that /lib/libc.so *is* used, but only by binaries that were
built on an FHS distro and that you’d bring in (that’s the whole point,
I guess).  It’s not used by Guix packages.

>> 1. Can we make the implementation more orthogonal and less entangled
>> in the already-long ‘launch-environment/container’?
>> 
>> Maybe that can be accomplished by moving all the code conditional
>> on ‘emulate-fhs?’ out of the way in a separate procedure, and
>> possibly by adding a generic hook in ‘launch-environment/container’
>> that would call said procedure.
>> 
>
> Sure, this sounds like a good idea. I can certainly separate out the FHS 
> setup to a separate function and call it. But I'm not sure what you mean by a 
> "generic hook" here. Do you mean that launch-environment/container would have 
> as an argument say a list of functions it would call?

Yes, or an argument with a single procedure to call at a specific
point.  That would default to a no-op.

>> 2. Please add tests. You can probably augment
>> ‘tests/guix-environment-container.sh’ for that. Let us know if
>> you’re not sure how to do that.
>> 
>
> Thanks, definitely forgot about that. In looking at that, I've just ran it 
> with "./pre-inst-env sh tests/guix-environment-container.sh" and see that the 
> exit code is 0. Is that the correct way to run these?

The correct way is:

  make check TESTS=tests/guix-environment-container.sh

Compared to what you wrote, it uses ./test-env (which spawns a daemon
that uses the local store, not /gnu/sore) and sets a bunch of
environment variables.

See
<https://guix.gnu.org/manual/devel/en/html_node/Running-the-Test-Suite.html>.

> Secondly, I'm trying to think of what tests to add. I could of course run the 
> same tests already, but with the --emulate-fhs option, to check that there 
> are no regressions. Other than that, maybe checking that e.g. there's 
> /etc/ld.so.cache, /lib, and so on?

Right, at least you’d want to check for these files/directories.

Note that since the test relies on ‘glibc-for-fhs’, it cannot be done
the “normal way” (that is, using the local store rather than /gnu/store)
because it would end up building the world.

The solution here is to use /gnu/store, if available, and to otherwise
skip the test (return 77).  See ‘tests/guix-pack-relocatable.sh’ up to
line 40 on how to do that.

HTH!

Ludo’.