On Sun, Jul 17, 2005 at 03:37:38PM -0500, Adam Majer wrote: > Steve Langasek wrote:
> >Package: libhoard
> >Version: 2.1.0-3
> >Severity: serious
> >Justification: Policy 8.4
> >The libhoard package contains a libhoard.so file which is *not* a symlink to
> >libhoard.so.*. This violates all the rules governing shared library
> >packaging; it makes it impossible to properly support installation of
> >multiple concurrent versions of the shared library, and it means that
> >installing future versions of -dev packages will force removal of any
> >packages dynamically linked with this libhoard.so. These
> >forward-compatibility issues make libhoard 2.1.0-3 unsuitable for inclusion
> >in a stable release.
> >Either libhoard must have a properly versioned soname and be split into -dev
> >and runtime packages, or the shared library must be dropped completely from
> >the package.
> Err, this is on purpose. libhoard is suppose to be a malloc/free drop-in
> replacement. If you try to get the soname,
> objdump -x libhoard.so | grep SONAME
> there is none. The reason is that there are only two functions that
> libhoard really exports - free and malloc. Those will not change. I
> don't think ABI for C linking will change either :)
> Also, you are not suppose to link with libhoard.so. You are suppose to
> preload it for the applications you want to use the Hoard memory
> allocator. From the readme,
Then libhoard.so should not be located in /usr/lib, per Policy 10.2.
Shared object files (often .so' files) that are not public libraries,
that is, they are not meant to be linked to by third party executables
(binaries of other packages), should be installed in subdirectories of
the /usr/lib' directory. Such files are exempt from the rules that
govern ordinary shared libraries, except that they must not be
installed executable and should be stripped.[2]
Thanks,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
