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? Do you think it is reasonable to replace all shared libraries usages with opt-in use of dlopen()? >> 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. You would have: Package: coreutils Depends: ... no libsystemd anywhere ... Recommends: coreutils-systemd Package: coreutils-systemd Depends: ... libsystemd ... Where the 'coreutils' package would only contains the applications that do not need systemd, and the 'coreutils-systemd' package would contain the applications (who, pinky, users) that need libsystemd. What's wrong with this? Users will barely notice, and you get the opt-in approach to libsystemd without forcing libsystemd on all of the coreutils packages. /Simon
signature.asc
Description: PGP signature
