On Thu, Aug 11, 2005 at 07:41:08PM +0200, Mike Hommey wrote: > I'm about to remove the libxslt1 package, which has been created a long > time ago for backward compatibility, when upstream did screw up ABI and > removed support for the libxsltbreakpoint library. > Now that no package depend on it, I am going to remove it, but that > leaves a libxslt1.1 package alone, not really respectful of the debian > standards for package naming. > I was wondering if I should come back to good practice and provide a > libxslt1 package with the library, and a dummy libxslt1.1 package for > upgrade support (which should only be removed after etch release). > It could break some external stuff depending on old libxslt1 (thus > libxsltbreakpoint), but are there really any left outside of debian ? > So, what do you think ? Should I just leave it the way it is now or try > to make it cleaner ? I think leaving it as-is would be the better option. The ideal state is to never have to reuse a library package name for something with an incompatible interface; which is exactly what you would be doing here, so I can only see that being justified if you expect a future upstream version to have libxslt1.1 as the soname. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature