curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem
Domenico Andreoli
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/.
doesn't this still scare you? then try to figure what will happen when
you install the first package depending on libcurl3-gnutls on a system
with openoffice (or php4-curl, vorbis-tools, ...) installed.
i realized this only while i was writing the packages conflicts but the
more i think at it the more i feel nervous. libcurl3 has ~80 rdepends
(when they became so many?!?) and i'd like to not be f*cked too hard
trying to figure the best solution.
should i really let 7.14.0-5 be installed? should i change the soname of
the gnutls variant? i suppose other packages already had this problem,
any wise advice?
many thanks.
cheers
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
> should i really let 7.14.0-5 be installed? should i change the soname of
> the gnutls variant? i suppose other packages already had this problem,
> any wise advice?
Stop building the openssl version *at all*.
Or if some broken program *really* needs it until it can be fixed, then
build it with a different soname, but make the gnutls version the
default one.
--
ciao,
Marco
Paul TBBle Hampson
> 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.)
If the problem isn't that the ABI changes, I'm not clear on why the gnuTLS
change was rolled back. (Bug #321294 implies the ABI changed but the soname
didn't, while #321391 is simply that the curl-config program doesn't report SSL
support, which should be easy to fix, and rolling back the transition was the
response of maximal-surprise to me. ^_^)
If the gnuTLS version is deficient in functionality, but doesn't affect the
ABI or soname, then the best thing to my mind would be to have the two
packages conflict and also provide libcurl3, and have the gnuTLS version
conflict with packages that use functionality that it doesn't support.
That way, either one of libcurl3 and libcurl3-gnutls can be installed, unless:
A GPL package (which only depends on libcurl3-gnutls) is installed:
libcurl3-gnutls gets pulled in
A package that can't work with gnuTLS version of libcurl (and
therefore libcurl3-gnutls conflicts with it) is installed:
libcurl3 gets pulled in
Packages of both above types are installed:
Unresolvable. However, this is also not possible now, unless
a GPL package is linking against the OpenSSL-using libcurl,
and therefore the GPL package has an RC bug.
Of course, this solution requires some work as you test each rdependancy
against libcurl3-gnutls. And they would have to be versioned conflicts,
since later versions of that rdependancy might work with the gnutls version,
and if they don't, should take the conflict with libcurl3-gnutls upon
themselves. (And maybe file a bug report against libcurl3-gnutls about the
missing functionality so that when it is fixed, the maintainer knows about
it and can remove the conflict.)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.H...@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/
-----------------------------------------------------------
Domenico Andreoli
> 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].
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.
cheers
domenico
[0] http://curl.haxx.se/mail/lib-2005-08/0118.html
Marco d'Itri
> 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.
What is the point then? They *will* be needed at the same time.
If they cannot be installed on the same system then looks like you are
wasting your time.
That "solution", BTW is a disgusting hack.
Again, there should be no reasons to need to use a openssl instead of
gnutls. If some program really needs it, then it should be linked to a
*special* libcurl-with-openssl library until it can be fixed.
But the default should be to use gnutls.
--
ciao,
Marco
Domenico Andreoli
> On Aug 24, Domenico Andreoli <ca...@debian.org> wrote:
>
> > 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.
> What is the point then? They *will* be needed at the same time.
> If they cannot be installed on the same system then looks like you are
> wasting your time.
the conflict is temporary. as soon as curl is fixed with this regard the
conflict will be removed and the packages depending on libcurl3-gnutls
will be bugged to be rebuilt.
> That "solution", BTW is a disgusting hack.
Daniel will be surely happy to see better patches. regarding me,
i prefer disgusting over inexistent.
if only Daniel liked the idea of using plugins in curl... eh, Daniel?
> Again, there should be no reasons to need to use a openssl instead of
> gnutls. If some program really needs it, then it should be linked to a
> *special* libcurl-with-openssl library until it can be fixed.
> But the default should be to use gnutls.
gnutls is not mature, it has been just added. people willing to test
it and signal bugs are welcome.
Paul TBBle Hampson
> 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.
Steve Langasek
> > 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].
> 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.
Hrm, I'm not clear on *why* openssl vs. gnutls should have an effect on
the ABI (as opposed to just differing in functionality). Do you have a
pointer on this?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Henrique de Moraes Holschuh
> 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
That is not enough. You also need versioned symbols in all conflicting
libraries, i.e. there must be no symbol clash between openssl and gnutls,
nor between curl3 linked to openssl and curl3 linked to gnutls.
This is important for libs linking against curl3, otherwise they can break
any application that links to them and uses curl3 itself. If no libs ever
link against curl libs, this is not an issue.
sonames are for pre-link-time dependency handling (i.e. to select what to
try linking to). During the linkage, versioned symbols (plus some other
black magic like weak aliases,etc) are used, and the soname is not even
brought into play.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Thomas Bushnell BSG
> A GPL package (which only depends on libcurl3-gnutls) is installed:
> libcurl3-gnutls gets pulled in
>
> A package that can't work with gnuTLS version of libcurl (and
> therefore libcurl3-gnutls conflicts with it) is installed:
> libcurl3 gets pulled in
>
> Packages of both above types are installed:
> Unresolvable. However, this is also not possible now, unless
> a GPL package is linking against the OpenSSL-using libcurl,
> and therefore the GPL package has an RC bug.
It could certainly be resolved: different libraries should install
different files.
Henrique de Moraes Holschuh
> Paul TBBle Hampson <Paul.H...@anu.edu.au> writes:
> > A GPL package (which only depends on libcurl3-gnutls) is installed:
> > libcurl3-gnutls gets pulled in
> >
> > A package that can't work with gnuTLS version of libcurl (and
> > therefore libcurl3-gnutls conflicts with it) is installed:
> > libcurl3 gets pulled in
> >
> > Packages of both above types are installed:
> > Unresolvable. However, this is also not possible now, unless
> > a GPL package is linking against the OpenSSL-using libcurl,
> > and therefore the GPL package has an RC bug.
>
> It could certainly be resolved: different libraries should install
> different files.
You also need different SYMBOLS. Which requires symbol versioning, and that
the symbols provided bu curl+gnutls be differently versioned than the
symbols provided by curl+openss.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Olaf van der Spek
> Henrique de Moraes Holschuh <h...@debian.org> writes:
>
> >> It could certainly be resolved: different libraries should install
> >> different files.
> >
> > You also need different SYMBOLS. Which requires symbol versioning, and that
> > the symbols provided bu curl+gnutls be differently versioned than the
> > symbols provided by curl+openss.
>
> libraries must never provide the same symbol names.
But doesn't it make much more sense to ensure no two libraries provide
the same symbol?
Thomas Bushnell BSG
>> It could certainly be resolved: different libraries should install
>> different files.
>
> You also need different SYMBOLS. Which requires symbol versioning, and that
> the symbols provided bu curl+gnutls be differently versioned than the
> symbols provided by curl+openss.
This would be nice too, but Debian does not have a rule that different
libraries must never provide the same symbol names.
Thomas Bushnell BSG
If they have compatible APIs.
So: if they are compatible, then yes, they should cover the same
namespace, and then each should Provide the same package name.
Or, if they are not, they should provide different symbol names.
Or, as a second-best, they could be in different file names, with
colliding symbol name spaces.
Or, as the absolutely worst, they could be the same file name and the
packages could conflict.
Unfortunately, the last "solution" has been chosen.
Henrique de Moraes Holschuh
> Henrique de Moraes Holschuh <h...@debian.org> writes:
> >> It could certainly be resolved: different libraries should install
> >> different files.
> >
> > You also need different SYMBOLS. Which requires symbol versioning, and that
> > the symbols provided bu curl+gnutls be differently versioned than the
> > symbols provided by curl+openss.
>
> This would be nice too, but Debian does not have a rule that different
> libraries must never provide the same symbol names.
Of course we don't. It is a bug if you try to link to two libs that cause a
symbol clash. OTOH, if you don't ever try to link them, why would we forbid
it?
So, find another excuse. Maybe there is a better way of fixing the bug (my
favourite would be to fully version openssl and gnutls, and get libcurl to
not change ABIs at all when linked to either. You'd only need to link
libcurl to gnutls, then. No more license headaches).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Olaf van der Spek
> If they have compatible APIs.
>
> So: if they are compatible, then yes, they should cover the same
> namespace, and then each should Provide the same package name.
>
> Or, if they are not, they should provide different symbol names.
>
> Or, as a second-best, they could be in different file names, with
> colliding symbol name spaces.
>
> Or, as the absolutely worst, they could be the same file name and the
> packages could conflict.
>
> Unfortunately, the last "solution" has been chosen.
Just wondering, why?
Is it that hard to enable 'different' symbols?