[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WIP Patch] Adding an FHS container to guix shell
From: |
John Kehayias |
Subject: |
Re: [WIP Patch] Adding an FHS container to guix shell |
Date: |
Fri, 15 Jul 2022 16:00:05 +0000 |
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
- [WIP Patch] Adding an FHS container to guix shell, John Kehayias, 2022/07/12
- Re: [WIP Patch] Adding an FHS container to guix shell, Vagrant Cascadian, 2022/07/12
- Re: [WIP Patch] Adding an FHS container to guix shell, Dominic Martinez, 2022/07/12
- Re: [WIP Patch] Adding an FHS container to guix shell, zimoun, 2022/07/14
- Re: [WIP Patch] Adding an FHS container to guix shell, Liliana Marie Prikler, 2022/07/14
- Re: [WIP Patch] Adding an FHS container to guix shell,
John Kehayias <=
- Re: [WIP Patch] Adding an FHS container to guix shell, Maxim Cournoyer, 2022/07/15
- Re: [WIP Patch] Adding an FHS container to guix shell, Maxim Cournoyer, 2022/07/15
- Re: [WIP Patch] Adding an FHS container to guix shell, Ludovic Courtès, 2022/07/18
- debbugs irritation Was: [WIP Patch] Adding an FHS container to guix shell, Csepp, 2022/07/20