[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option.
From: |
Ludovic Courtès |
Subject: |
[bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option. |
Date: |
Thu, 08 Sep 2022 22:58:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
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’.