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

> 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.

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.

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.