Re: Linking coreutils against OpenSSL
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
Reply to: