On Tue, 16 May 2023 at 09:27, Simon McVittie <s...@debian.org> wrote: > > On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote: > > This sounds like a very interesting use case, and the first real one > > mentioned, which is great to see - but I do not fully follow yet, from > > what you are saying it seems to me that what you need is for your > > binaries to use the usual pt_interp, that bit is clear. But why does > > it matter if /usr/bin/ls on the host uses a different one? > > We don't need to run the ls from the host, but we do need to run > glibc-related executables like ldconfig and localedef from either the > host or the container runtime, whichever is newer. Because glibc is > a single source package, executables and libraries within the glibc > bubble sometimes make use of private symbols in libraries that are also > within the glibc bubble (and IMO they have a right to do so), even though > executables from outside glibc would be discouraged or disallowed from > doing so. This means that when we have chosen a particular version of > glibc (which, again, must be whichever one is newer), we try to use its > matching version for *everything* originating in the glibc source package. > > In principle we could get exactly the same situation if we've imported a > library from the host system (as a dependency of the graphics stack) that > calls an executable as a subprocess and expects it to be >= the version > it was compiled for - hopefully not (/usr)/bin/ls, but potentially others.
Thanks for the clarification, so if I understood correctly, your use case is that sometimes (eg: when they are newer) you pull binaries (eg: ldconfig) from the host, and run them from the container? So, in case let's say ldconfig on the host points to /usr/lib/ld, but because your container is not usr-merged, it wouldn't find the interpreter and fail? > The wider point than my specific use-case, though, is that when there's a > standard, you can't predict what other software authors have looked at the > statement "you can rely on this" and ... relied on it. See also Russ's > (as ever, excellent) mails to the same thread. > > I appreciate that you are trying to explore the edges of the > problem/constraint space and say "what if we did this, could that work?", > and it's good that you are doing that; but part of that process is > working with the other people on this list when they say "no, we can't > do that because...", and respecting their input. I respect and appreciate the input, but I want to understand it too, hence the "because..." part is what I was looking for - so thanks for providing it, it is really useful. Kind regards, Luca Boccassi
