On Wed, Aug 24, 2005 at 03:54:38PM +0200, Domenico Andreoli wrote: > On Fri, Aug 19, 2005 at 12:07:09PM +1000, Paul TBBle Hampson wrote: >> On Thu, Aug 18, 2005 at 11:00:41AM +0200, Domenico Andreoli wrote: > >> with curl 7.14.0-5 currently in incoming, i added two new packages > >> libcurl3-gnutls and libcurl3-gnutls-dev. libcurl3 and libcurl3-gnutls > >> conflict each other since both install libcurl.so.3.0.0 in /usr/lib/. >> >> If the problem is that using gnutls or openssl changes the ABI for libcurl, >> then they should have different sonames. (I'd expect the newer one, gnuTLS, >> would get its own soname, so that existing packages work, and packages can >> optionally build against the gnuTLS version if they so wish. Once everything >> builds happily against the gnuTLS version, the next upstream soname bump can >> use the gnuTLS library, and we're compatible with other distributions again.) > problem is right the change of ABI. > Daniel Stenberg (the upstream developer) is available to implement a > solution based on the proposal of Richard Atterer [0]. The issue in the above is that the suggestion of two different versions of libcurl being a problem for prog A is only a problem if the sonames/sovers are not differentiated, and I suggest they _be_ differentiated. I mean, they provide different ABIs. Will the openSSL version provide dummy gnuTLS entries as well? And what about a different ssl implementation? pssl, or whatever it's called? If you want to have one ABI no matter which libraries are being used, then you need to provide an ABI that abstracts away anything SSL, and doesn't require the curl-using program to care what it's linked against. _Then_ you provide a pair of curl packages, one with openSSL and one with gnuTLS, same soname and sover, both providing libcurl3, and programs that need the functionality of the openSSL version can conflict with the libgnutls version of the library, and programs that don't care can use either. However, that's not a huge improvement over now, while my below suggestion allows GPL'd curl-using programs to be uploaded without having to remove openssl-needing curl-using programs. > in the meanwhile new packages can be built using the gnutls variant of > libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot > be installed at the same time. I'd again suggest changing the soname of the gnuTLS libcurl to something else, since the changed ABI means that programs must choose to build against one or the other, and so it's not a problem if programs need to be told to link against libcurl-gnutls3.so instead of libcurl3.so, since presumably no other distro is trying to simultaneously support both openSSL and gnuTLS versions of libcurl, which is the strongest motivation for keeping upstream's soname. ^_^ And then the two packages can be parallel-installed, avoiding this particularly nasty issue in this proposed solution. I cannot see what motivation there is to only have one of the library pacakges installed. The _dev_ packages need to conflict as they provide the same API, of course. This also means you need to produce a -dev pacakge for both libcurl and libcurl-gnutls. Those programs that know they need the gnuTLS version of libcurl can build-depend on libcurl-gnutls-dev and so they'll have libcurl-gnutls.so.3 in their library load list instead of libcurl.so.3. Programs which are unhampered by licenses can try out the gnuTLS version, and if it works, the can use that, or stick with the openSSL version until the gnuTLS version matures and can fully replace the openSSL version as libcurl.so.4. (And a bit of trickery with the libcurl-gnutls4-dev would mean anything built against that gets the unified libcurl4 dependancy.) The _important_ point is that no pair of programs becomes uninstallable due to conflicts between their dependant curl library versions. I'm not sold on the idea of run-time dynamic choosing of openSSL vs a stub, and for that matter it means the issue of curl-config --features (my bug report from way back when) becomes a lot more complicated. -- ----------------------------------------------------------- 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:
pgph7G_IUQRvE.pgp
Description: PGP signature