On Sat, Sep 03, 2005 at 08:16:48AM +1000, Paul TBBle Hampson wrote: > As far as packaging goes, this means you get the following packages: > libcurl3, providing libcurl3-openssl (linked against OpenSSL to avoid breaking > sarge packages that use this functionality) > libcurl3-gnutls (linked against gnuTLS, doesn't support SSL_CTX_FUNCTION) > libcurl3-dev (Do we need a second -dev? Static linking maybe requires it? If > this becomes a testable feature, then a second -dev is definately needed.) > Packages which don't use SSL_CTX_FUNCTION can Depend on either libcurl3 | > libcurl3-gnutls, or if they're GPL'd can depend on libcurl3-gnutls only. > Packages which need SSL_CTX_FUNCTION can depend on libcurl3-openssl > grepping the source of libcurl3's direct rdepends should tell you which > packages in Debian need SSL_CTX_FUNCTION. > GPL'd packages which need SSL_CTX_FUNCTION are out of luck. And have always > been so. > Before etch ships, no package should depend on libcurl3, they should depend on > libcurl3-openssl or libcurl3 | libcurl3-gnutls or libcurl3-gnutls. > After etch ships, upload: > libcurl3, providing libcurl3-gnutls (linked against gnuTLS) > libcurl3-openssl, providing libcurl3 (linked against openSSL) > libcurl3-dev > At this point, packages who don't like having libcurl3-gnutls is their > Depends line can do a versioned depends on libcurl3, which won't match > the libcurl3 virtual dependancy provide by libcurl3-openssl, and will > also prevent them accidentally linking against an openSSL version of > libcurl3. (At least, I _think_ that's how versioned dependancies on > virtual packages work. Possibly they'll _always_ match, in which case a > Conflicts is in order instead.) Do libcurl3 and libcurl3-gnutls provide different sonames to allow co-installability of the packages, or does libcurl3 use diversions to override the libcurl.so.3 that lacks SSL_CTX_FUNCTION support (if any) when installing? (We know that directly conflicting between the two packages is not really an option, unless we're doing this like the C++ ABI transition and we either don't believe there are any packages in Debian which will need to retain SSL_CTX_FUNCTION support or we assume they're packages that we don't care about co-installability of -- which seems far-fetched to me.) The latter may require excessive amounts of license patrolling, because one could have a package which depends on libcurl3-gnutls but also has dependencies which force libcurl3 to be pulled in. The former would make it rather impractical to migrate the libcurl3 association from -openssl to -gnutls in etch+1. > The _problem_ with this setup is you can't parallel-install a GPL'd > libcurl3-using application and an application that uses SSL_CTX_FUNCTION > (as libcurl3 and libcurl3-gnutls must conflict as they provide shared libs > with the same soname/sover. As you'd expect as they're ABI-compatible, > albeit functionaly different.) The impact of this should be taken into > account, and balanced against the fact that right now, we can't have > a GPL'd libcurl3-using application installed at all. ^_^ Ah, so you were aiming for conflicts between the packages after all... :/ The worry I have with balancing it against not having GPLed libcurl3-using applications is that we do currently seem to be doing ok without libcurl support in those packages right now, but there may be many packages with optional libcurl support that'll get enabled, leaving the packages that need the OpenSSL support *virtually* uninstallable. > There are possibly some optimisations that could be made above with Conflicts. > Maybe both -openssl and -gnutls should provide libcurl3, all users depend on > libcurl3, and GPL packages conflict with libcurl3-openssl and SSL_CTX_FUNCTION > users conflict with libcurl3-gnutls. I'm not sure if this is an improvement... It isn't; it doesn't ensure a smooth upgrade path for apps in sarge. It may be worthwhile to simply survey all the curl-using packages in sarge, though, and find out if there is a non-zero number of them that need SSL_CTX_FUNCTION. If *not*, then I don't think there's much sense in going through a multi-stage transition: just switch libcurl3 directly to gnutls, and add libcurl3-openssl which provides libcurl-openssl.so.3? -- 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/
Attachment:
signature.asc
Description: Digital signature