Re: ongoing curl transition pain
On Fri, Jun 15, 2007 at 05:13:57PM +0200, Domenico Andreoli wrote:
> I should have figured out the change to symbol versioning was not
> required at all... so I agree in reverting it.
Great!
> > - 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?
Because we will be binary-incompatible with the existing libcurl4 packages,
so we want to enforce a rebuild of all packages built against the current
version and to protect users from having incompatible versions installed
together.
Just rolling back the package name completely is the simplest name change
option that I see; you could reintroduce libcurl3* /and/ rename the current
libcurl4 packages to something else, but I think that's unnecessary
complexity, especially given that we would ideally keep libcurl3* around
anyway through the release of lenny to make the upgrade process as smooth as
possible.
> > - 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.
SSL stuff is part of the base system; libssl0.9.8 and libgnutls13 are both
Priority: important. I don't think SSL-less systems are a relevant use
case.
> > 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?
Yes, except for the part where it's harder to keep broken package
combinations from trickling into testing. :)
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: