Modestas Vainius writes:
> On pirmadienis 23 Lapkritis 2009 23:35:28 Russ Allbery wrote:
>
>> Debian tries to avoid RPATH used in ways that might break multilib or
>> override local administrator settings, which means we want to avoid
>> RPATH pointing to /usr/lib or to build directories and the
#include
* Josselin Mouette [Tue, Nov 24 2009, 12:00:34AM]:
> Le lundi 23 novembre 2009 à 15:30 +0300, Nikita V. Youshchenko a
> écrit :
> > Moving package-private shared libraries outside of /usr/lib is some amount
> > of additional work that maintainer has to do.
>
> Yes. This is one of the r
Hello,
On pirmadienis 23 Lapkritis 2009 23:35:28 Russ Allbery wrote:
> Debian tries to avoid RPATH used in ways that might break multilib or
> override local administrator settings, which means we want to avoid RPATH
> pointing to /usr/lib or to build directories and the like. But RPATH is
> th
Le lundi 23 novembre 2009 à 15:30 +0300, Nikita V. Youshchenko a
écrit :
> Moving package-private shared libraries outside of /usr/lib is some amount
> of additional work that maintainer has to do.
Yes. This is one of the reasons why there are maintainers instead of
robots.
> If it is not a req
"Nikita V. Youshchenko" writes:
> 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?
Yes.
> debian tries to avoid rpath AFAIK ...
Debian tries to avoid RPATH used in ways that might break multilib or
overri
> > 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 ...
>
> Just because we hunt down stupid rpath cases doesn’t mean there aren’t
> valid uses for it. And this
Le lundi 23 novembre 2009 à 14:39 +0300, Nikita V. Youshchenko a
écrit :
> 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
> 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
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
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
> > > pos
> On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote:
> > Hi
> >
> > I tried to prepare and NMU to fix an RC bug #553111, which is
> > postinst-must-call-ldconfig.
> >
> > I found that adding missing call to dh_makeshlibs does not fix the
> > issue, because package installs a priva
On Mon, Nov 23, 2009 at 13:33:17 +0300, Nikita V. Youshchenko wrote:
> Hi
>
> I tried to prepare and NMU to fix an RC bug #553111, which is
> postinst-must-call-ldconfig.
>
> I found that adding missing call to dh_makeshlibs does not fix the issue,
> because package installs a private shared l
Hi
I tried to prepare and NMU to fix an RC bug #553111, which is
postinst-must-call-ldconfig.
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 po
13 matches
Mail list logo
