On Fri, Jun 26, 2026 at 3:26 PM David Laight <[email protected]> wrote: > On Fri, 26 Jun 2026 14:39:22 +0200 > Jann Horn <[email protected]> wrote: > > > On Thu, Jun 25, 2026 at 10:50 AM Christian Brauner <[email protected]> > > wrote: > > > The arguments I have heard from various people so far are: > > > > > > (1) Userspace would be able to clone a random chroot to /woot and run a > > > binary from it without having to set up a complicated sandbox > > > effectively making dynamically linked binaries more like static > > > binaries in a sense. > > > > > > (2) Quote: > > > "If you debootstrap/dnf a chroot to some location in your > > > home dir and try to run a binary from it, that it tries to load the > > > libraries from your /usr is a pretty unintuitive and not at all > > > useful behavior." > > > > > > (3) Quote: > > > "[Various remote execution things run in locked down containers that > > > disable userns, which makes the sandbox impossible and hence our > > > builds wouldn't work there." > > > > FWIW I think someone also mentioned to me that it would make things > > easier for them if they could build a piece of software in one > > environment and then bundle it up with all required libraries and such > > and run it in a very different environment, without > > container/sandboxing stuff and without static linking. But I guess > > that's kinda niche. > > The problem with 'ship the shared libraries with the application' is > that you get all the problems of static linking. > If there is a bug in the library code you can't fix it without getting the > 3rd party to rebuild their application package.
Yes, it's appropriate for weird use cases like "I want to run this historical version of the software and its dependencies", it's not necessarily a good idea for normal application use.
