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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
