ongoing curl transition pain
Hi Domenico,
We talked a while back about the curl transition, and about how upstream's
change from libcurl.so.3 to libcurl.so.4 is gratuitously painful for us in
light of the large number of reverse dependencies.
The libcurl transition has at this point gotten tangled with soname
transitions in jasper, exiv2, kexiv2, and God only knows what else. So I'd
like to revisit this question, because tracking this transition is costing
the release team a lot of time that would be better spent elsewhere, and
removing the need for a libcurl transition promises to reduce the complexity
of the other components by an order of magnitude.
On looking at the curl package, I've come to understand that the symbol
versioning in place in this library is the result of a Debian-local patch.
That's great news, because it suggests a solution to this quandary that
doesn't require an unreasonable amount of developer time.
I am proposing the following:
- Keep the library soname the same as it currently is upstream. Because
upstream uses unversioned symbols, our package will be binary-compatible
with applications built against the upstream libcurl regardless of what we
do with symbol versioning, so leaving the soname alone minimizes the
amount of patching to be done against upstream code here.
- *Revert* the Debian symbol versioning to the libcurl3 version, and make
libcurl.so.3 a symlink to libcurl.so.4. We have already established that
libcurl.so.4 is still API-compatible with libcurl.so.3, in spite of the
soname change upstream; reverting the symbol versioning will make it fully
ABI-compatible with libcurl.so.3, and adding the symlink lets
previously-built binaries find it.
- Revert the Debian package names to the curl 7.15.5 versions. Because
compatibility has been restored with libcurl3 and libcurl3-gnutls,
restoring the package names provides the best upgrade path from etch to
lenny; and because the symbol versions have been reverted, the libraries
are not binary-compatible with the Debian packages currently named
libcurl4/libcurl4-gnutls/libcurl4-openssl (in spite of being
binary-compatible with upstream), so it would be wrong to keep the current
names regardless.
- Drop the SSL-less variant of the library, which was not present in curl
7.15.5; AFAICS, there is no use case where a user of curl *needs* to *not*
have SSL support, so this split seems to be unnecessary overhead. Please
correct me if I'm mistaken.
- Leave the -dev package names alone otherwise, to simplify binNMUing of the
reverse-dependencies (some packages have already added versioned
build-deps on libcurl4.*-dev -- I have no idea why -- so reverting the
names would mean more work to chase down those packages). Drop
libcurl4-dev as a binary package, though, in favor of being Provided by
libcurl4-gnutls-dev. Many of the packages currently build-depending on
libcurl4-dev -- including some that wrongly used libcurl3-dev before --
are GPL, and these are apparently all packages where having SSL support
missing in libcurl4 wasn't hurting them, so libcurl4-gnutls-dev seems to
be the reasonable "default" here.
- Schedule binNMUs for all reverse-dependencies.
As a result of these changes, curl 7.16 can proceed into testing as soon as
it alone is ready to go, without breaking any of the reverse-dependencies;
and each reverse-dependency can follow it as soon as it too is ready.
Please let me know if you see any technical disadvantages to this solution.
The attached patch is a preliminary implementation of what I describe, which
I am in the process of testing. If you approve of these changes, I would
like to see this uploaded to unstable (via NEW) ASAP, either as a maintainer
upload or as an NMU, so that we can un-stick the several hundred packages
currently blocked by this together with other, uncoordinated and untimely
soname changes.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: