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.
Reply to: