Hi, On 2023-11-09 07:31, Theodore Ts'o wrote: > If you can get upstream a patch so that coreutils could try to dlopen > OpenSSL and use it if it is available, but skip it if it is not, that > might be one way to avoid OpenSSL going into essential. The challenge > is that OpenSSL is not known for its ability to maintain a stable ABI, > but if we only care about supporting a specific version of OpenSSL > (the one which is shipped with coreutils) and given that the fallback > is a slower sha256sum, which IMHO is *not* a disaster, perhaps it's > doable?
This idea seems appealing to me. In terms of costs vs benefits, adding OpenSSL to essential has a fairly high cost for unclear benefits. Costs, from Policy 3.8 [1]: "Maintainers should take great care in adding any programs, interfaces, or functionality to essential packages. Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an essential package therefore creates an obligation to support that capability as part of the Essential set in perpetuity." Can we quantify the benefits? Not in terms of artificial benchmarks, but real use cases if possible. [1] https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages