reopen 318590
thanks

hi dear developers,

it looks like i completely underestimated the transition of curl to
gnutls [0]. so i have just made a new upload which settles the things
back to openssl.

i don't want to start any transition right now, also because upstream
developer made me note that the gnutls support is still young.

these are bad news for those gpl packages waiting for libcurl with no
openssl. they will have to wait a little more. i'm sorry for this.


in talking about the solution IMHO things get hotter.

probably the next simpler solution is to add libcurl3-gnutls and,
if required, libcurl3-gnutls-dev packages. but somebody could prefer
a -nossl version (like that still in woody, the one i should have
never removed).

<rant>
BTW what about gssapi support? kerberos or heimdal?

hmmm... there is smell of combinatorial explosion. debian is about
choice, not explosions, isn't it? how much it is for choice and how
much is for explosions?
</rant>

i continue to think that having only a curl+gnutls package is the
long term solution but i'll be glad to hear also your opinion and
suggestions. [1]


thank you
domenico


[0] probably because i never wanted to start such transition. my hope
was to (ingenuously) hide the change within the curl build process.

[1] yes, recently a thread talked right about curl and openssl vs. gnutl
s,
but evidently i didn't see what i call a general consensus.

-----[ 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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Sat, Aug 06, 2005 at 02:10:29AM +0200, Domenico Andreoli wrote:
> <rant>
> BTW what about gssapi support? kerberos or heimdal?

> hmmm... there is smell of combinatorial explosion. debian is about
> choice, not explosions, isn't it? how much it is for choice and how
> much is for explosions?
> </rant>

Mmm, FWIW, there are no license issues with MIT/Heimdal Kerberos that would
necessitate having two builds.  I'm not sure if there are other reasons
currently to prefer one over the other except in talking with particular
servers, but one certainly shouldn't try to do dual builds of packages
unless such use cases manifest.

> i continue to think that having only a curl+gnutls package is the
> long term solution but i'll be glad to hear also your opinion and
> suggestions. [1]

Agreed, but of course the source has to be in a state to allow that.

-- 
Steve Langasek
postmodern programmer

[ Post a follow-up to this message ]

On Sat, 06 Aug 2005 the mental interface of
Domenico Andreoli told:

> reopen 318590
> thanks
>
> hi dear developers,
>
>   it looks like i completely underestimated the transition of curl
>   to gnutls [0]. so i have just made a new upload which settles
>   the things back to openssl.

Bad idea to switch to ssl only 

> i don't want to start any transition right now, also because
> upstream developer made me note that the gnutls support is still
> young.

But still works ;-)

> these are bad news for those gpl packages waiting for libcurl with
> no openssl. they will have to wait a little more. i'm sorry for
> this.

It is quit easy to create separated gnutls-packages.

> in talking about the solution IMHO things get hotter.

?

> probably the next simpler solution is to add libcurl3-gnutls and,
> if required, libcurl3-gnutls-dev packages. but somebody could
> prefer a -nossl version (like that still in woody, the one i
> should have never removed).

Readd it!

[...]
> i continue to think that having only a curl+gnutls package is the
> long term solution but i'll be glad to hear also your opinion and
> suggestions. [1]

Should be short term. As mentioned many times before, do it ;-)

[...]
> [1] yes, recently a thread talked right about curl and openssl vs.
>     gnutls, but evidently i didn't see what i call a general
>     consensus.

IMHO provide both, ssl and gnutls.

Elimar
--
It's a good thing we don't get all
the government we pay for.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Sun, 7 Aug 2005, Elimar Riesebieter wrote:
 
>
> IMHO provide both, ssl and gnutls.

I can only agree.

Even when libcurl works identically good using either library, OpenSSL and
GnuTLS differ not only license-wise but they also have features of their own
and bugs of their own. Limiting the libcurl offer to use only one of them wi
ll
cause grief at some point in some camp(s), that's for sure.

--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Aug 9 2005, Steve Langasek wrote:

(I'm not on the list, I read this response elsewhere and I handicraft this
reply)
 
[vbcol=seagreen]
> Er, it's only SSL/TLS.  The correct long-term answer to "they each have
> bugs" is "fix the bugs in [libcurl's support for] GnuTLS", not "let th
e
> users pick which set of bugs they like better".

I beg to differ. A lot.

1. It is not "only" SSL/TLS. For example, OpenSSL supports SSLv2 while
GnuTLS does not. GnuTLS supports SRP while OpenSSL does not.

If an author of an application that uses libcurl cares about either of
these differences, then that author might prefer one specific of these libs.

2. In the mail you replied to I was referring to bugs in the SSL/TLS
libraries, not the ones in libcurl. It is similar to (1) above, as the
authors of the libs might prioritize bugs differently or even disagree on
what a bug is or isn't etc.

3. There are application authors who _prefer_ the license of OpenSSL in
favour if the (L)GPL ones of GnuTLS (and its associated sub-libraries). So
even if the libs were identical, I think the license differences alone is
reason enough for two packages.

4. As these SSL libs provide completely different APIs they allow somewhat
different things to be done with different ease or even possibilities. I
don't find it unlikely that libcurl will offer different features to
applications depending on what underlying SSL lib that is used. This would
of course not be ideal or even wanted, but in real life it might still be
what we'll have.

There, I've stated my opinions. I'll refrain from further replying in this
topic now.

--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.or
g

[ Post a follow-up to this message ]

On Tue, Aug 09, 2005 at 11:31:22PM +0200, Daniel Stenberg wrote:
> On Aug 9 2005, Steve Langasek wrote:

> (I'm not on the list, I read this response elsewhere and I handicraft this
 
> reply)
 
[vbcol=seagreen] 
[vbcol=seagreen]
> I beg to differ. A lot.

> 1. It is not "only" SSL/TLS. For example, OpenSSL supports SSLv2 while
>    GnuTLS does not. GnuTLS supports SRP while OpenSSL does not.

>    If an author of an application that uses libcurl cares about either of
>    these differences, then that author might prefer one specific of these 
>    libs.

That's a lousy justification for shipping two otherwise-identical binary
packages.  Unless there's a reason that GNU TLS upstream objects to
supporting SSLv2, the answer is still "get SSLv2 support added to GNU TLS",
not "make it everybody else's problem to support double the binaries".

> 2. In the mail you replied to I was referring to bugs in the SSL/TLS
>    libraries, not the ones in libcurl. It is similar to (1) above, as the
>    authors of the libs might prioritize bugs differently or even disagreeo
n
>    what a bug is or isn't etc.

<shrug>  Irrelevant to my argument.  I had [libcurl's support for] in
brackets for a reason.

> 3. There are application authors who _prefer_ the license of OpenSSL in
>    favour if the (L)GPL ones of GnuTLS (and its associated sub-libraries). [/vbcol
]

Then those application authors are insane.  I try to avoid depending on
software written by crazy people; you never know what else their insanity
might lead them to do.
[vbcol=seagreen]
> 4. As these SSL libs provide completely different APIs they allow somewhat
>    different things to be done with different ease or even possibilities.I
>    don't find it unlikely that libcurl will offer different features to
>    applications depending on what underlying SSL lib that is used. This 
>    would
>    of course not be ideal or even wanted, but in real life it might stillb
e
>    what we'll have.

Which again fails under "there are bugs, fix them instead of making
everybody else support your lack of effectiveness as a maintainer".

-- 
Steve Langasek
postmodern programmer

[ Post a follow-up to this message ]