From: "Ludovic Courtès" <ludo@gnu.org>
To: John Kehayias <john.kehayias@protonmail.com>
Cc: 56677@debbugs.gnu.org
Subject: [bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option.
Date: Thu, 08 Sep 2022 22:58:59 +0200 [thread overview]
Message-ID: <87leqtd1m4.fsf_-_@gnu.org> (raw)
In-Reply-To: <lRCczsf4p1BjaKh298oj36OxIGgAcLEuAtW6_T9YQxsLmYH03GZC3fEHPFrlskHHhMr8bXT9Sa2D3-i6aCvbCzgP2Hj1h1SBV7wvpwN5400=@protonmail.com> (John Kehayias's message of "Wed, 17 Aug 2022 21:43:08 +0000")
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’.
next prev parent reply other threads:[~2022-09-08 21:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-21 4:14 [bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option John Kehayias via Guix-patches via
2022-07-21 4:19 ` [bug#56677] [PATCH 1/2] gnu: Add glibc-for-fhs John Kehayias via Guix-patches via
2022-07-21 4:19 ` [bug#56677] [PATCH 2/2] environment: Add '--emulate-fhs' John Kehayias via Guix-patches via
2022-08-02 14:27 ` [bug#56677] [PATCH 2/2 v2] " John Kehayias via Guix-patches via
2022-08-04 10:36 ` [bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option Ludovic Courtès
2022-08-17 21:43 ` John Kehayias via Guix-patches via
2022-09-08 20:58 ` Ludovic Courtès
2022-09-08 20:58 ` Ludovic Courtès [this message]
2022-10-04 18:32 ` [bug#56677] [PATCH v2 1/2] " John Kehayias via Guix-patches via
2022-10-13 7:37 ` [bug#56677] [PATCH 0/2] " Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87leqtd1m4.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=56677@debbugs.gnu.org \
--cc=john.kehayias@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).