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

Re: ongoing curl transition pain

On Thu, Jun 14, 2007 at 04:37:42PM -0700, Steve Langasek wrote:
> Hi Domenico,

Hi Steve,

> 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.

Sorry for the headaches :/

> 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.

I should have figured out the change to symbol versioning was not
required at all... so I agree in reverting 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.

Why not simply re-add old libcurl3-openssl and libcurl3-gnutls with a
symlink to newer libcurl4 counterparts?

This way newly built packages would get dependencies on the new packages
bringing the mess to a soname consistent package naming in some future,
maybe allowing to drop libcurl3* before lenny.

> - 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.

I made this to allow thos not willing to install any SSL-related stuff
but never checked it is really possible. IIRC I was even asked for it.
Anyway I don't feel strong on it, if it as to go away it will.

> - 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.


> 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.

This should still hold also with my variation of your proposal,
shouldn't it?

> 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.



-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Reply to: