On Mon, Dec 04, 2006 at 07:38:13AM +0100, Laszlo Boszormenyi wrote: > > Based on my understanding of the license requirements and the compatibility > > of the two libs, I would suggest one of two solutions:
> > - make libneon26-gnutls Provide: libneon26, and keep the current shlibs > > as-is > > - change the shlibs of libneon26 to libneon 26 libneon26 | libneon26-gnutls, > > but leave the shlibs of libneon26-gnutls as-is > > 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? > > It also assumes that there's really a reason for separate gnutls and OpenSSL > > flavors of the package. I'm not sure what that reason is. > See above. All neon dependant package looks for libneon.so to link > with. So if I change the GnuTLS compiled libneon.so to libneon-gnutls.so > then there will be linkage problems if the source is not altered to look > for libneon-gnutls.so instead of libneon.so . 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. > I emphasis, as all source looks for libneon.so and both the OpenSSL and > GnuTLS neon produce the same library name (libneon.so), that's why I > have the separate packages and so conflict with each other. > See above if I alter the neon sources to provide libneon-gnutls.so when > compiled with GnuTLS. The question is, *why provide a version of neon linked against OpenSSL at all*? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
