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, 04 Aug 2022 12:36:06 +0200 [thread overview]
Message-ID: <87r11wmh2h.fsf@gnu.org> (raw)
In-Reply-To: <1LCXD7_zuGflSFovh_mKvhdayNcoWp8ALeguq3i2-XWwWHgzZuPak2gSBN91VLNJ84lubuFAt1dPB282Zy0pBmh_zbiI2qI-7n0LP9F03u4=@protonmail.com> (John Kehayias's message of "Thu, 21 Jul 2022 04:14:19 +0000")
Hello,
John Kehayias <john.kehayias@protonmail.com> skribis:
> As discussed on guix-devel here (please see for more detailed discussion and design aims): https://lists.gnu.org/r/guix-devel/2022-07/msg00161.html this is a patch to add an FHS (Filesystem Hierarchy Standard) emulation option for environments.
Wo0t!
> 1. On the mailing list there was discussion about the necessity or not of glibc-for-fhs (added in the first patch). I find this useful and a big piece of making this FHS option work, but open to discussion or if it should be a further option.
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.
It seems that ‘glibc-for-fhs’ is merely added to the environment though,
and not actually used?
+ ;; For an FHS-container, add the
+ ;; (hidden) package glibc-for-fhs which
+ ;; uses the global cache at
+ ;; /etc/ld.so.cache.
+ (if emulate-fhs?
+ (alist-cons 'expression
+ '(ad-hoc-package
+ "(@@ (gnu packages base) glibc-for-fhs)")
+ opts)
+ opts)))
Or rather it’s only used when running ‘ldconfig’, right?
> 2. Right now I used a script written to the containers /tmp/fhs.sh to generate the ld cache, supplement $PATH (somewhat optional, but I found useful for less tinkering), and finally launch the given command or shell. I found that when not providing a command the prompt for /bin/sh is not the same as when not using --emulate-fhs. So I'm not sure if this is the correct way to launch the default /bin/sh if no command is given. Open to ideas of a better way to implement these actions for a container start up as well.
>
> 3. This is my first time touching a guix script and the documentation, so please do check the commit message and guix.texi.
>
> 4. I decided to link the second level FHS directories, like /usr/bin, as well as optional ones like /lib64 (or /lib32), to the top level /bin, /lib, and so on. These could just be bind mounted to profile/bin and so on as well, but again tried to mimic an FHS distribution like Arch where the files only live in one place. While perhaps making the code a little more involved, I hope this makes the container look tidier.
>
> I may be forgetting other elements in the implementation decisions I made, but I have been testing these patches along the way and have gotten good usage of them. Please test further too!
At first sight, I find it pretty cool! I would have two grievances:
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.
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 for all the work, and sorry for the delay: it seems to be summer
time for many of us. :-)
Ludo’.
next prev parent reply other threads:[~2022-08-04 10:37 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 ` Ludovic Courtès [this message]
2022-08-17 21:43 ` [bug#56677] [PATCH 0/2] environment: Add --emulate-fhs option John Kehayias via Guix-patches via
2022-09-08 20:58 ` Ludovic Courtès
2022-09-08 20:58 ` Ludovic Courtès
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=87r11wmh2h.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).