On Sat, Sep 03, 2005 at 05:02:14AM -0700, Steve Langasek wrote: > 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.) Ooops. I forgot about diversions. And yes, I'm expecting them to conflict. If they don't want to conflict, I believe the suggestion I posted much earlier about changing coname for the gnuTLS version would do it, but it makes the transition more painful in my opinion. > 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? Very true... apt-cache rdepends libcurl3: libcurl3 Reverse Depends: python-mapscript php4-mapscript perl-mapscript openoffice.org2-core mapserver-bin cgi-mapserver ida xmms-scrobbler xine-ui xen xastir wmweather wmget vorbis-tools telak tclcurl sylpheed-claws-gtk2-clamav streamtuner rtorrent redland-utils rasqal-utils raptor-utils python2.4-pycurl python2.3-pycurl python2.3-librdf python2.2-librdf python-mapscript php5-curl php4-curl perl-mapscript paintlib2c2 openoffice.org-bin moc metar mapserver-bin logjam linuxtrade libwww-curl-perl libsword5 libstonith0 librdf0 librdf-ruby librdf-perl librasqal0 libraptor1 libofx2 libmultisync-plugin-opie liblrdf0 libcurl3-gssapi libcurl3-gssapi libcurl3-gnutls libcurl3-dev libcurl3-dbg libcurl-ocaml libclamav1 libapache2-webkdc libapache2-webauth jigdo jabber-msn icecast2 grip gnomesword gambas-gb-net-curl freepops fbi drivel diatheke darcs-server darcs curl cogito clamcour clamav-milter clamav-freshclam clamav-daemon clamav cgi-mapserver centericq-utf8 centericq-fribidi centericq cduce came bzflag-server bzflag bidwatcher bibletime beep-media-player-scrobbler ardour-gtk-i686 ardour-gtk apt-spy approx aegis-web aegis apt-get source `apt-cache rdepends libcurl3 |grep '^ '` --download-only Move the following out of the way: curl_7.14.0-5 fbi_2.01-1.2 gnomesword_2.1.2-2 ida_2.01-1.2 libwww-curl-perl_2.0-8 openoffice.org_1.1.4-7 openoffice.org2_1.9.125-1 pycurl_7.14.0-2 sword_1.5.8-2 tclcurl_0.13.2-1 for d in *.dsc; do dpkg-source -x $d; done grep -r CURLOPT_SSL_CTX_ */. gives just two hits, curl_lua in freepops, and they just return 'unimplemented' when called. So apart from the above 10 pacakges, no one in the archive is using CURLOPT_SSL_CTX_* that I can see. As for the rest: BINDINGS: * curl itself only uses it in - lib/url.c (implementation) - tests/libtest/lib509.c (test of functionality) - docs/examples/curlx.c (demonstration of usage) * libwww-curl-perl doesn't use it itself, but exports it for perl users to use. (But it doesn't show any rdepends here...) * pycurl doesn't support it. * tclcurl documents it as not supported CDBS and other multi-unpack tarballs * fbi doesn't use it * ida doesn't use it * sword doesn't use it * gnomesword doesn't use it Stuff that filled my hard disk while unpacking next to everything else: * openoffice.org (includes its own version of curl in the .orig.tar.gz) doesn't use it. * openoffice.org2 doesn't use it. So unless I'm missing something, this is a complete non-issue... You could upload a libcurl3 built against gnuTLS, and see what breaks. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
pgpAXXwd9pQ2j.pgp
Description: PGP signature
