[sr-dev] Conflict between libcurl4-gnutls-dev and libcurl4-openssl-dev (Debian)

[Henning Westerholt]

On Dienstag, 23. Juni 2009, you wrote:
> > is it inherited in this case? the tls implementation in core of kamailio
> > is binding directly to openssl library and therefore need for the gpl
> > disclaimer, but in this case utils binds to curl library.
> >
> > In sip router this is fixed I guess and tls is shipped with debs --
> > anyhow, tls is a module in sr, the core is the same.

Hi Jan,

> If I understand it correctly, we are talking here about Debian control
> files that are being kept in the git repository, right? But aren't those
> files intended for people who want to build Debian packages themselves,
> rather than for official Debian developers? As far as I know official
> Debian developers maintain their control files elsewhere, and in fact it is
> recommended that upstream projects do not provide their own control files.

sure, our debian control files are different then the official ones. And they 
are maintained in a different repository, e.g. in "pkg-voip" for kamailio. But 
they are synchronised from time to time.

> If this is the case, does it really matter if we keep libcurl4-openssl-dev
> in our control files? We know that all the stuff should work (at least was
> developed with) with openssl, so shouldn't this be the default for the
> people who attempt to build the packages themselves?
>
> Also note that the -dev packages are only needed to actually build
> packages, they are not needed at runtime. They only contain files that are
> needed to compile applications that use libcurl. Corresponding runtime
> libraries are in libcurl3 (openssl version) and libcurl3-gnutls (gnutls
> version) and these can be installed at the same time. What this means is
> that it is not possible to *compile* applications for use with
> libcurl-openssl and libcurl-gnutls at the same time.

I've nothing against it, just wanted to note that it makes packaging a bit 
harder from a debian POV.

Henning

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20090623/b20f71d1/attachment.htm>