Hi all,
Dimitri drew my attention to this bug and the associated PR, because Ubuntu
is now in the process of transitioning to openssl 1.1 as well, and we have
somewhat shorter timelines in order to complete the transition in time for
Ubuntu 18.04 LTS (releasing in April).
Alessandro wrote:
> last time a transition of libcurl was attempted some 10 years or so ago,
> it was halted for reasons now lost in the mists of time, so we have been
> stuck carrying some hacks to pretend we are still using the old SONAME
In fact, some of us who remember are still around ;-) The historical
context here is that curl upstream made a determination that the SONAME
should be bumped for an "ABI break" that was not an ABI break in any
traditional sense, didn't appear to break compatibility in any meaningful
way, and imposing this as an SONAME transition in Debian would simply make
upgrades brittle for no real reason.
Maintaining compatibility was the right thing to do.
However, compatibility was maintained in a way that *also* maximized
portability of binaries between Debian and other distributions, by adopting
the libcurl.so.4 SONAME and providing libcurl.so.3 as a symlink (and
retaining the libcurl3 package name) for backwards-compatibility in Debian.
Now, it appears that somewhere along the way, upstream adopted symbol
versioning which is incompatible with that used in Debian, because upstream
symbols are named CURL_${FLAVOR}_4 and ours are named CURL_${FLAVOR}_3. So
that's somewhat unfortunate, and means we're no longer as binary-compatible
as we were. However, symbol versioning is great, and it's entirely possible
to fix the libraries to be binary-compatible with all versions of both
upstream and Debian binaries which ship the same ABI.
Which brings me to the first question: if this is an ABI break with
existing libcurl.so.4, what is curl upstream's position on SONAME changes?
In 2007, they were quite aggressive about renaming in the face of possible
API breaks - are they now ignoring an ABI break that will straight up cause
callers to segfault?
I think it's always best practice to follow upstream's behavior wrt SONAMEs,
and to always change package names when we know that the ABI we're exposing
has changed. So if upstream is changing the SONAME because of this
transition, then it's easy to follow them and change the package name at the
same time. But if upstream is not changing the SONAME, we should change the
package name while keeping the same SONAME and adding conflicts against
libcurl3.
Now, the other thing is:
> Due to the fact that the previous transition (libcurl3 -> libcurl4) was
> partially reverted (in 2007 according to the changelog), I'd also like to
> taeke this opportunity to finally complete that as well, so I made a patch
> to not only rename libcurl3 -> libcurl4, but also (libcurl3-gnutls,
> libcurl3-nss) -> (libcurl4-gnutls, libcurl4-nss), and remove the hacks
> needed to keep compatibility with the previous ABI.
I think this is a very bad idea.
The ABI is breaking due to changes to an OpenSSL object type being returned
by the library. This means that the ABI is changing *only* for the OpenSSL
variant of the library.
And, in Debian unstable:
$ apt-cache rdepends libcurl3 | wc -l
115
$ apt-cache rdepends libcurl3-gnutls | wc -l
378
$ apt-cache rdepends libcurl3-nss | wc -l
8
$
Changing the package names for the libraries whose ABI has *not* changed
(and does not need to be changed by Debian, wrt SONAME or symbol versions)
will make the transition 4x bigger than it would be from changing libcurl3
alone. If anything, if you do believe that it's important to clean up the
library package names in a way that forces a transition (which I have argued
against above), then you should at least do this /separately/ from the
transition of libcurl3 for openssl, in order to not entangle the two
otherwise-unrelated transitions.
And as Adrian writes:
>> Maybe it would be wise to suggest to upstream to bump major 4 to a 5 to
>> signal that this libcurl exposes the libssl1.1 ABI now.
> "now" was 2016.
> Back then this would have been a valid point, but after other
> distributions already ship with OpenSSL 1.1 and the old libcurl soname it
> is too late for that.
> The package name is the only thing we can change without diverging from
> other distributions.
So, despite Julien's valid objection that core library conflicts cause
dist-upgrades to be more brittle, I think the right answer here is:
- keep all sonames as-is.
- rename libcurl3 to libcurl4.
- leave the package names of the other variants as-is.
- *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
elsewhere outside the Debian ecosystem, fix the symbol versions for
libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that CURL_FOO_4
is used as the preferred name and CURL_FOO_3 is for compatibility only.
(This is only worth doing if this increases binary compatibility;
otherwise it's better to maintain bidirectional binary compatibility for
Debian-built binaries.)
- change the symbol versions for libcurl4 to CURL_OPENSSL_4.
I would be willing to prepare a patch that implements this.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature