On 2013-10-12 Eric Valette <eric.vale...@free.fr> wrote:
> On 12/10/2013 08:06, Andreas Metzler wrote:
>>On 2013-10-11 Eric Valette <eric.vale...@free.fr> wrote:
>>>That is where it breaks. I do not mind rebuilding curl myself and
>>>did it but it is impossible to install.
>>if you changed [1] the curl packages to build against gnutls28 you would
>>need to adapt the dependencies too, i.e. make libcurl4-gnutls-dev
>>depend on libgnutls28-dev.
>>
> Hi andreas,
> First thanks for your support. Indeed this would work but I think
> the correct path is for libgnutls26-dev to provide libgnutls-dev and
> for libgnutls28-dev to conflict with libgnutls26-dev like many other
> library package do. I still do not get the name change. This way
> you can still install curl along with libgnutls26 but need to
> rebuild or downgrade if you intend to use libcurl*dev.
Hello Eric,
that's a couple of questions. ;-)
Q1 Why do we have
-----------
Package: libgnutls28-dev
Version: 3.2.4-4
Provides: gnutls-dev
Conflicts: gnutls-dev
Package: libgnutls-dev
Version: 2.12.23-8
Provides: gnutls-dev
Conflicts: gnutls-dev
-----------
instead of
-----------
Package: libgnutls28-dev
Version: 3.2.4-4
Provides: libgnutls-dev
Conflicts: libgnutls26-dev
Package: libgnutls26-dev
Version: 2.12.23-8
Provides: libgnutls-dev
Conflicts: libgnutls28-dev
-----------
A1: Look at it, there is no inherent benefit, it is the same thing
just with other identifiers. In the current regime a package would
have to use "Depends: gnutls-dev" to require *any* gnutls development
package, while with your sugestion it would write "Depends: libgnutls-dev".
Also, packages usually do not depend on *any* arbitrary version of
gnutls development. They usually want either "at least version x" or
commonly "the corresponding development suite of the runtime library
we are linking against".
So we end up with the refined question:
Q2: Why are two different versions of gnutls in sid and why do both
ship development packages, instead of rebuilding everything against
the new version and transitioning to it.
A2:
a) Licenses. Aaargh. The GnuTLSv3 stack ends up being licensed LGPLv3+
which is incomapitible with GPLv2 (without "or later"-clause).
b) Some API incompatibility. While most packages just work with
GnuTLS3 some packages break, most often because they rely on gcrypt
being automatically available when gnutls is used.
Usually in Debian we try to not change the name of the development
package when the runtime soname changes, as it requires changing
everything the build-depends on the package instead of a straight
rebuild. Gnutls is different, since we are forced to ship both
versions for an extended period of time.
Q3: Why does libcurl4-gnutls-dev enforce installation of the gnutls26
development package ("libgnutls-dev") instead of depending on any
version of gnutls development ("gnutls-dev")?
A3: Afaict the dependeny exists mainly to allow static linking. And
this requires that the correct version of libgnutls.a is present, i.e.
one that is ABI compatible with the one curl was built against.
> The other nice things
> would be to provide libcurl based on libgnutls28 in experimental.
That would work, but is a curl issue.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
