On Mon, 20 Jul 2026 at 20:18, Simon Josefsson <[email protected]> wrote: > > Luca Boccassi <[email protected]> writes: > > > On Mon, 20 Jul 2026 at 19:41, Simon Josefsson <[email protected]> wrote: > >> > >> Luca Boccassi <[email protected]> writes: > >> > >> >> For the readutmp situation, the extra complexity does not appear to be > >> >> worth it. > >> > > >> > Why is it not worth it? They are different use cases, worth something > >> > different to different people. One is not better or worse or different > >> > or more worth or less worth than the other. It's exactly the same > >> > code, to achieve the exact same goal: make a dependency > >> > runtime-optional. Incidentally, if it wasn't already a dlopen dep, > >> > this patch would have made it into one as well, for the same reason. > >> > >> Where should the line be drawn? > > > > Up to the point people are willing to do the work, as with everything else > > > >> Do you think it is reasonable to replace all shared libraries usages > >> with opt-in use of dlopen()? > > > > In some cases, yes. Every single dependency (bar glibc) in systemd is > > as of now a runtime-optional dlopen library. It works really nicely, > > and allows a single build to be fully-featured while still maintaining > > arbitrary composability. > > Would you argue the same for LibreOffice or some similar package? > > I think your argument only works for a quite limited number of packages, > and I'm not even sure the balance is right even for a low-level package > like coreutils.
If it works for systemd and its 32 dependencies, I don't see why it wouldn't work for coreutils > >> >> Yet another option is that we could split GNU 'coreutils' into two > >> >> packages. Arguably 'who', 'pinky' and 'users' are no longer core > >> >> utilities, if so many users do not care whether they work. > >> > > >> > End result is worse: more complex, more annoying to handle, less > >> > flexible, less powerful. And doesn't really help anyway: it's the same > >> > story for libselinux, which affects more binaries. > >> > >> I don't understand that argument -- packages are split into several > >> sub-packages all the time, and users are used to this. > >> > >> With my Debian (non-coreutils maintainer) hat on, this seems like a good > >> way to resolve this. > > > > It's really not, every time functionality is expanded or moved, > > binaries need to move too, and as we know dpkg is atrociously bad at > > handling that. > > It requires a bit of work (writing proper Depends/Recommends/Breaks and > doing testing), but definitely much less than you are asking for here, > right? I've moved binaries between packages a couple of times, and > while it may not be a pleasant task, it works. Not at all, as it's constant churn, while the work here is already done, and once done, that's the end of it > > If every binary gains such functionality, you are back to square > > one. It's really not a good way to organize things, as it's > > fundamentally disjoint: the way features are implemented, and the way > > subpackages are split out, are completely orthogonal and independent > > and do not move in unison. > > Often they are related though. It seems the tools that need libsystemd > in coreutils are multiuser tools, and those do not feel particulary > relevant in a container. They could go into a separate package. There's no law of physics that says different functionality unrelated to "multiuser" can't appear in the future, and then what happens?
