On Thu, 16 Jul 2026 at 19:47, Paul Eggert <[email protected]> wrote: > > On 2026-07-16 11:14, Luca Boccassi wrote: > > We are not going to add random per-package scripts and hacks. > > OK, your call. > > > After umpteen emails, you still have failed to raise a single issue > > with the actual patch > > Sure we have: it complicates coreutils and adds maintenance burden. From > the upstream point of view, why add random hacks to make it easier for > distros to purposely break some apps? Admittedly this is a judgment call > - just as the rejection of the optional-libsystemd script is a judgment > call - but it's seems reasonable for upstream to say "Umm, no" here.
What "maintenance burden" did using dlopen for openssl add? It's a header, a list of symbols and dlsym calls. It's of course work to implement it and test it initially, that's for sure. But once implemented, it's just there and it just works. And I know this from experience, given I have about ~30 dlopen dependencies I maintain in systemd. The first ones were added years ago. The burden was to add support for all of that, and then the surrounding infrastructure. After the initial work, it's really not been any burden, really. > > why isn't the > > same issue already affecting openssl? I don't see any > > "optional-openssl" script for it > > For that situation, the extra complexity is worth it, as it speeds up > 'sort' in the usual case and it makes 'sort' a bit more reliable. > > 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. > Another option is that Debian could maintain a downstream patch along > the lines you're proposing. (A downstream patch along the lines I'm > proposing would also work, although you've rejected that.) Debian > coreutils already has a patch for something else, so the mechanism for > downstream patches is already there. This is useful for all main distributions, not just one. > 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.
