Package: curl Version: 7.18.0-1 Severity: wishlist Hi,
It seems to me, but you can correct me if I'm wrong, that nowadays, the https/ssl API in curl is backend agnostic, i.e. the API and ABI is the same between libcurl-gnutls and libcurl-openssl. Which means applications building against libcurl, whatever license they are released in, use a standard ABI that can be provided at runtime by any of these 2 packages. Reverse dependencies could then depend on a virtual libcurl3 package that would be provided by both. And not depending on a specific backend using incompatible license, rdepends licensed under the GPL without openssl exception should be distributable just fine. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages curl depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii libcurl3 7.18.0-1 Multi-protocol file transfer libra ii libkrb53 1.6.dfsg.3~beta1-2 MIT Kerberos runtime libraries ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime curl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
