On Mon, 2006-12-04 at 20:24 -0800, Steve Langasek wrote: > On Mon, Dec 04, 2006 at 07:38:13AM +0100, Laszlo Boszormenyi wrote: > > > This ensures that any package that should avoid being linked against > > > OpenSSL > > > for license reasons will get the gnutls flavor of the library, but other > > > packages can link against either flavor. > > OK, I have to change the GnuTLS version to libneon-gnutls.so then. > > No. Why would you want to do that? Adam Majer said I may do it, as long as -dev packages have a link libneon.so to the correct neon library (libneon.so.0.26.2 or libneon-gnutls.so.0.26.2) it would be OK. The -dev packages would be ok to conflict with each other.
> No, this is a very bad idea. No application linking against libneon should > *care* whether it's linked with gnutls or not; you should *not* expose this > in the library name. You are right, that's why I made them conflict with each other, as both provide the same library name. Would be the proposed -dev change be acceptable? > The question is, *why provide a version of neon linked against OpenSSL at > all*? Upstream develop with OpenSSL, GnuTLS support has been just added, not tested too much. Should work, but close to releasing Etch I don't want to break Subversion and/or OpenOffice.org . Still, upstream will develop with OpenSSL, I can not garantee that it will always work and have the same security support. Also it would fetch more dependencies (GnuTLS related just for neon) and I don't know if Subversion serving over https would interfere with Apache2 or not. Reason: Apache2 is linked with OpenSSL, Subversion and neon will be linked with GnuTLS. For now, I will ask what upstream says about this. Please decide if I should switch to GnuTLS support only; but then please schedule binNMUs for Subversion and OpenOffice.org . Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
