[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: