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. > >> 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. 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.
