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.
Reasonable
> 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.
ok
Thanks,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Reply to: