Steve Langasek wrote: > severity 401388 important > thanks I'd knew you were going to do that! :)
> > On Sat, Dec 02, 2006 at 08:25:05PM -0600, Adam Majer wrote: > >> AFAIK, library packages cannot conflict with each other. > > Sure they can... But this screws up usability of Debian as a whole if half of the packages cannot be installed because another half is compiled with a library that conflicts with former. I really think that policy should be fixed (or must be fixed, to use the correct wording :) such that libraries cannot conflict with each other unless, * same ABI (one provides the other though shlibs files) * any application can link with one or the other (licensing issues only in this point) >> What should change is that libneon26-gnutls should provide a file with >> an alternate soname and an alternate filename. As per policy 8.1, > > Alternate sonames are used when the library ABI is different. If the > library ABI is the same, it's reasonable to show this by using the same > soname. Then shlibs should be updated such that all packages that build with one or the other can link dynamically link with one or the other. This brings up license issues though due to OpenSSL. > How this is best handled at the packaging level is debatable, but there are > certainly cases where conflicts are the obviously correct solution (e.g., > C++ ABI transitions). > >> Furthermore, both are listed as priority optional packages which >> doesn't follow section 2.5 of the Policy, > > True, though policy also lists this as a 'should', per your quote. Yes, most of the stuff in the Policy states should.... Needless to say, libneon should be fixed to not conflict with each other. There is no reason to do this. I'm sure you'd agree with me on this. It affects usability of libneon. It might as well be that libneon-gnutls would not be provided at all. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
