Re: Packages violating policy 8.2
On 19 May 2006, Goswin von Brederlow outgrape:
setools is in the list, and contains libraries that it uses
itself, but does not break it up into multiple installed
packages. Setools is moving rapidly rnough that I do not intend to
support multiple versions of the libraries until things stabilize a
bit.
However, people do build binaries against these libraries, and
even have private packages, and I intend to support that.
> For some (or a lot?) packages the maintainer may claim that they
> don't contain public shared libraries, only package internal shared
> objects.
> Then why do you have shlib files [only spot checked for that]?
Allows private packages to have proper dependencies.
> If no other package is supposed to link against your shared object
> then why not link it in static?
Because multiple binaries in the package linking to the
libraries do reduce the memory usage?
> 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?
Again, this it to allow people who do follow selinux to create
their own packages, with the caveat that these packages become
unuseable as soon as new versions of setool are released.
> 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.
setools is not a shared library package, per se. It is a
package that provides tools for SELinux, and also happens to
distribute some shared libraries the tools use, and does not want to
play LC_CONFIG games.
> Unless there is some reason not to I plan to file RC bugs at least
> against the 53 packages containing "lib" in the package name.
well, setools does not have lib in the name, so I guess this
does not apply.
manoj
--
Once the toothpaste is out of the tube, it's hard to get it back
in. H.R. Haldeman
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: