i noticed that in debian squeeze, libcurl3-dev has been replaced by libcurl4-openssl-dev. perhaps 'libcurl3-dev' in Build-Depends entry of debian/control should thus be changed to 'libcurl3-dev | libcurl4-openssl-dev' ?
-- juha
El Sat, 25 Sep 2010 12:25:58 +0300 Juha Heinanen jh@tutpro.com escribió:
i noticed that in debian squeeze, libcurl3-dev has been replaced by libcurl4-openssl-dev. perhaps 'libcurl3-dev' in Build-Depends entry of debian/control should thus be changed to 'libcurl3-dev | libcurl4-openssl-dev' ?
-- juha
Hi Juha
The libcurl3 dependency remains because there was just one "debian" folder in the past. Now (at least in kamailio packaging) we have one debian folder per debian version and should be safe to change libcurl3 for libcurl4 in the control file.
Anyways, this is not an issue really since libcurl4 "provides" libcurl3:
quenya:/home/manwe# apt-cache show libcurl4-openssl-dev Package: libcurl4-openssl-dev Version: 7.21.0-1 Replaces: libcurl-dev, libcurl-ssl-dev, libcurl3-dev (<< 7.14.1-1), libcurl3-openssl-dev Provides: libcurl-dev, libcurl-ssl-dev, libcurl3-dev, libcurl3-openssl-dev
It may be better for now to use libcurl gnutls version because tls module and any other module linked to openssl directly or via other libs (like libcurl) don't work together.
Cheers, Daniel
On 9/25/10 12:57 PM, Jon Bonilla (Manwe) wrote:
El Sat, 25 Sep 2010 12:25:58 +0300 Juha Heinanenjh@tutpro.com escribió:
i noticed that in debian squeeze, libcurl3-dev has been replaced by libcurl4-openssl-dev. perhaps 'libcurl3-dev' in Build-Depends entry of debian/control should thus be changed to 'libcurl3-dev | libcurl4-openssl-dev' ?
-- juha
Hi Juha
The libcurl3 dependency remains because there was just one "debian" folder in the past. Now (at least in kamailio packaging) we have one debian folder per debian version and should be safe to change libcurl3 for libcurl4 in the control file.
Anyways, this is not an issue really since libcurl4 "provides" libcurl3:
quenya:/home/manwe# apt-cache show libcurl4-openssl-dev Package: libcurl4-openssl-dev Version: 7.21.0-1 Replaces: libcurl-dev, libcurl-ssl-dev, libcurl3-dev (<< 7.14.1-1), libcurl3-openssl-dev Provides: libcurl-dev, libcurl-ssl-dev, libcurl3-dev, libcurl3-openssl-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
It may be better for now to use libcurl gnutls version because tls module and any other module linked to openssl directly or via other libs (like libcurl) don't work together.
daniel,
so now sr tls implementation is based on gnutls?
if so does it mean that when ua establishes tls connection to sr, it can tell for which realm the connection is intended for and sr thus supports multiple tls realms, e.g., one per domain? if i remember correctly, in the early days openssl lib and kamailio didn't support this.
-- juha
Hello Juha,
On 9/25/10 2:47 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It may be better for now to use libcurl gnutls version because tls module and any other module linked to openssl directly or via other libs (like libcurl) don't work together.
daniel,
so now sr tls implementation is based on gnutls?
no, tls module is based on openssl, but because it changes the memory manager and other things in openssl lib it does not work at the same time with other modules linked to openssl lib that use default settings (same was in 1.5 or earlier).
if so does it mean that when ua establishes tls connection to sr, it can tell for which realm the connection is intended for and sr thus supports multiple tls realms, e.g., one per domain? if i remember correctly, in the early days openssl lib and kamailio didn't support this.
The tls module has support for multi-domain (iirc, Klaus added it some time ago), but you need a recent version of openssl.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Jon Bonilla -
Juha Heinanen