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

[Ludovic Courtès]

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’.