On Sat, Apr 14, 2001 at 05:29:20PM +0200, Daniel Kobras wrote: > I have prepared a package of libdv, a library to de- and encode digital > video data, and noted that it violates current policy: The x86 version > of the library contains optimized assembler routines that are not > relocatable. Therefore, the lib on x86 won't build as a shared library, > which is in conflict with the first paragraph of debian-policy sect. 11.2, > mandating also shared versions of each lib. I have contacted upstream > about this, and they prefer to keep libdv static-only for performance > reasons. When I brought up this issue on debian-devel, it was suggested > I build a libdv-dev package only across all archs and request a policy > change allowing static-only uploads as well in special cases. This is not secondable, because you do not have the text of a policy revision. However, I second the sentiment. There have been times when people package pre-1.0 versions of libraries and it causes great grief as the upstream breaks the API with great regularity. I would therefore suggest that any library whose major version number is zero (or otherwise in a development phase), should NOT provide a shared version. This leaves upstream authors free to do development during their development cycle(s) without feeling any pressure from Debian to stabilize their API prematurely, and it also decreases the chances of application breakage for users, because libs with version numbers of zero are a well-known exception to the soname incrementation rules. I really, really, really, don't miss crap like glib1.1.12_1.1.12-1, glib1.1.15_1.1.15-1, etc. -- G. Branden Robinson | Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. branden@debian.org | Chemistry is really physics. http://www.debian.org/~branden/ | Physics is really math.
Attachment:
pgpyqmNR7HHF5.pgp
Description: PGP signature