[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libcurl and moc



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)
Paul.Hampson@Anu.edu.au

"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/
-----------------------------------------------------------

Attachment: pgpkvIx_TTmbd.pgp
Description: PGP signature


Reply to: