[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unversioned .so file in /usr/lib vs dh_makeshlibs vs postinst-must-call-ldconfig



> On Mon, Nov 23, 2009 at 12:05:28PM +0100, Josselin Mouette wrote:
> > Le lundi 23 novembre 2009 à 14:00 +0300, Nikita V. Youshchenko a
> >
> > écrit :
> > > > > I found that adding missing call to dh_makeshlibs does not fix
> > > > > the issue, because package installs a private shared library to
> > > > > /usr/lib/libxxx.so, and dh_makeshlibs does not add call to
> > > > > ldconfig to postinst/postrm if it finds unversioned libraries.
> > > >
> > > > I'd say it's a bug in the package because private objects
> > > > shouldn't be installed in /usr/lib directly.
> > >
> > > Probably, however some packages do use that, and AFAIK this is not
> > > RC... or not?
> >
> > I think it fails to comply with policy §8.1.
> >
> > And regardless of the policy, it completely breaks the dependency
> > system, so it should be avoided.
>
> Actually, only the shlibs systems breaks. The symbols system supports
> .so files.
>
> Anyways, this may be a place where policy could be improved. While I do
> agree that in the general case we don't want unversioned sonames, there
> are a few cases where adding a debian specific soname breaks
> compatibility with other distros and upstream, while the library ABI is
> known or even guaranteed to be stable.
>
> What is the point of requiring so versioning when it is known there
> won't be any bump in version ? And even if there is such a bump, can't
> we just wait until it happens before adding incompatibilities ?
>
> Mike, with his nspr maintainer hat on.

I've also seen cases when upstream build system puts some code in 
a 'private shared library' which is installed into $prefix/lib, but is 
never intended to use outside of current package (and has absolutely 
unstable ABI, etc).

How to handle that case, if not putting private library as-is to /usr/lib ?

Move it to /usr/lib/packagename, and use rpath on binaries? debian tries to 
avoid rpath AFAIK ...
Or alter upstream's build system to stop producing shared library? that's 
at least maintaince headache without any win...

Nikita

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: