Re: Linking coreutils against OpenSSL

[Julian Andres Klode <jak@debian.org>]

On Sat, Nov 11, 2023 at 06:52:50AM +0100, Emanuele Rocca wrote:
> 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.
> 

WRT dlopen(), this is never an appealing solution because you do not
get any type-checking, you have to make sourceful changes for an soname
bump. It is an interface you can use for loading plugins (that is, you
should be in control of what the interface is that you are loading from
the library object), but it's not really usable for stuff that is outside
of your control.


> 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

I do not think this is a reasonable argument to make. While libraries
are dependencies of Essential packages, they themselves are
distinctively not Essential, they are pseudo-essential.

The rules here don't apply to pseudo-essential library packages because
quite frankly, they would have to apply to the specific soname because
that is the provided interface.

But since libraries frequently change their soname, they can't be 
considered subject to essential clauses because every soname bump,
you'd be removing a package from the essential set and adding a new
one to it.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en