Re: Packages violating policy 8.2
On Fri, 2006-05-19 at 18:44 +0200, Goswin von Brederlow wrote:
> Debian policy says:
>
> | 8.2 Run-time support programs
> |
> | If your package has some run-time support programs which use the
> | shared library you must not put them in the shared library
> | package. If you do that then you won't be able to install several
> | versions of the shared library without getting filename clashes.
> |
> | Instead, either create another package for the runtime binaries
> | (this package might typically be named libraryname-runtime; note the
> | absence of the soversion in the package name), or if the development
> | package is small, include them in there.
[snip]
> Package Maintainer
> -----------------------------------------------------------------------------
> qprof Al Stone <ahs3@debian.org>
> Then why do you have shlib files [only spot checked for that]?
For qprof, because that's how it works; it uses a shared library
plus LD_PRELOAD so it can capture performance information without
changing an application. The only "run-time binary" apart from
the .so is a script that sets LD_PRELOAD for you.
> If no other package is supposed to link against your shared object
> then why not link it in static?
Because then you can't use LD_PRELOAD and the package won't
work -- qprof is designed so you can collect performance data
without modifying your program. If you have to link in the
library to your application to collect performance data, you've
violated the basic premise of the package.
> If the library is only used for binary packages from the same source
> [which always get updated together] then why not put it in
> /usr/lib/package/ and make it not public?
This could be done for the qprof package. I'm not sure that qualifies
as an RC bug, though. Policy 8.2 never mentions that as a possibility;
it is perhaps implicit in the description, but not very obvious.
> I believe that if you have a shared object in (/usr)/lib then policy
> 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for
> multiarch. For multiarch this will not only give conflicts between
> different soversions of a library but also between different
> architectures of a library.
I can see how you came to that belief; having read 8.2 several
times before this, that was not an obvious conclusion to me.
Do you have any suggestions for ways to make the policy section
clearer? I haven't thought this through enough yet to make a
suggestion for improvement...
--
Ciao,
al
----------------------------------------------------------------------
Al Stone Alter Ego:
Open Source and Linux R&D Debian Developer
Hewlett-Packard Company http://www.debian.org
E-mail: ahs3@fc.hp.com ahs3@debian.org
----------------------------------------------------------------------
Reply to: