Re: [WIP Patch] Adding an FHS container to guix shell

[John Kehayias <john.kehayias@protonmail.com>]

Hi Liliana,

On Thursday, July 14th, 2022 at 10:59 AM, Liliana Marie Prikler wrote:
>
>
> Hi John,
>
> Am Dienstag, dem 12.07.2022 um 15:59 +0000 schrieb John Kehayias:
>
(snip)
> > 2. Typically binaries will expect the ld loader to use
> > /etc/ld.so.cache for finding libraries. So, I made a glibc package
> > that removes our dl cache patch to restore this behavior. It seems
> > enough to add this as a default package to the container, though I
> > commented out an option to automatically graft everything with this
> > glibc. Both worked for me, but grafting didn't seem necessary.
>
> Would it make sense to keep our libc, but also symlink the cache to its
> FHS place? Or do we need to patch our libc so that this cache is tried
> if a Guix-specific one isn't found?
>

I think it may be possible, but I wasn't able to do this exactly in my efforts for a certain non-free package. So I don't remember the details exactly, but roughly I think it is that our libc will look based on $ORIGIN into a /gnu/store/.... location for an ld cache. I tried to make this happen with some symlinking in the container, but it didn't work for me (maybe just due to the complexity of the binary I was trying this with?). The general issue might just be making this adaptable if it could work. But admittedly I was doing a lot of guessing and learning, so maybe I just wasn't approaching this correctly. And then removing one patch was just too easy :)

As for patching libc so that it falls back to something like /etc/ld.so.cache, I would worry about undesired behavior on a foreign distro. Though we could have it look at some other location that wouldn't conflict (some special directory for Guix?). Still, this sounds like it would add complexity and difficult to diagnose behavior. Seems cleaner to me to distinguish the libc in the FHS container explicitly.

Still, I'm open to hear how this could work, just saying I wasn't able to figure it out using this approach before.

WDYT?

(snip)
> > What about other uses for this container, like providing an isolated
> > environment to build and run software we can't do fully with
> > bootstrap and sources (like JS)? Could this become some stop-gap to
> > allow people to work with these ecosystems in a more controlled way
> > within Guix? Or an alternative build environment? Not entirely sure
> > what this could mean, just thinking out loud.
>
> I don't think we should rely on FHS containers in the build system.
> It's nice to have such a feature as a user, who really needs
> $ELECTRON_APP and doesn't care about the fact that it's a packaging
> nightmare, but on a system level, we ought to provide abstractions that
> are meaningful and helpful to everyone, and FHS containers increase
> both the complexity and the failure potential. See also antioxidant-
> build-system as an example for making Rust packaging sane (we'll likely
> need a similar effort for JS).
>

Sure, I agree the main goal here is definitely for the end-user rather than building. Perhaps there are some applications in some building, but yeah, didn't have anything in mind.

> > [...]
>
> > +;;; Copyright © 2021 John Kehayias john.kehayias@protonmail.com
>
> Is this the right year?
>

[checks calendar] it is not. In fact, we're closer to 2023 than 2021 at this point.

Thanks for spotting!

> > + -F, --fhs-container run command within an isolated FHS
> > container"))
>
> Rather than adding "--fhs-container" as an alternative to --container,
> I'd like something like "--emulate-fhs", which as the "--networking"
> option is to be combined with -C. This makes the interface more
> symmetric.
>

Ah, this is a good idea. Then we would enforce that --container is also included when using the --emulate-fhs option. And the little code I figured out to hijack setting the container option without the user specifying it could be dropped to make it all more explicit from the command interface as well. I'll do that.

> > + (symlink lib-dir "/lib64")
> > + (symlink lib-dir "/lib")
>
> You'll probably want to split 32-bit libraries (if any) and 64-bit ones
> here. Also, bear in mind that certain architectures are 32-bit only.
>

Yes, thanks, I was sort of following what Arch does as my test case. But as pointed out by Maxim as well, we should keep a generic following of the standard. I would like some testing to know if some less standard links are widely used though, standards being one thing and what distros do in practice another. I'll also leave multiple arch setups for a followup, keeping this first attempt generic.

Thanks for the helpful comments!

John