Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

[Reinhard Tartler]

On Tue, Aug 31, 2010 at 20:50:05 (CEST), Jonas Smedegaard wrote:

> On Tue, Aug 31, 2010 at 06:48:21PM +0200, Reinhard Tartler wrote:
>>On Tue, Aug 31, 2010 at 17:44:38 (CEST), Jonas Smedegaard wrote:
>>
>>> On Tue, Aug 31, 2010 at 11:10:03AM -0400, Felipe Sateler wrote:
>>>>On 31/08/10 08:41, Jonas Smedegaard wrote:
>>>>
>>>>> I am not sure how to properly package non-public shared libraries.
>>>>>
>>>>> Please someone advice on this.
>>>>
>>>> Install into /usr/lib/<package> and use RPATH on the executables
>>>> using it. If upstream uses autotools, I think just passing an
>>>> appropriate libdir will do the right thing.
>>>
>>> So http://wiki.debian.org/RpathIssue do not apply to all shared libs,
>>> only public ones?
>>
>> yes. and BTW, I find rpath very acceptable for purely private shared
>> libraries. And even during development and local deployment, rpath is
>> pretty convenient.
>
> I do not doubt that rpath has sane uses.  What I assumed obvious but can
> state explicitly now to avoid possible confusion, is that my concern
> here is tied to official Debian packaging - not e.g. "local deployment".
>
> Do you mean to say that *for* *Official* *Debian* *packaging* it is safe
> to ship shared libraries with rpath when not installed in ldconfig
> supported paths?

Yes, I do.

>
>>> Currently the package generates an shlibs file and ldconfig snippets
>>> in postinst and postrm scripts.  Lintian then complains with these:
>>>
>>> W: scenic-utils: postinst-has-useless-call-to-ldconfig
>>> W: scenic-utils: postrm-has-useless-call-to-ldconfig
>>
>> ldconfig only indexes /lib and /usr/lib (and a few corner cases, but
>> not /usr/lib/$package, this is the point of putting them there)
>>
>>> Is it wrong of dh_shlideps to include subdirectory below /usr/lib?
>>
>> yes, because you do want to include the private libraries's library
>> dependencies, don't you?
>>
>>> Is it sane to pass -X/usr/lib to dh_shlibdeps to suppress it?
>>
>>no, see above.
>
> Sorry - I am confused: why not suppress wrongly included private shared
> libraries from being registered by dh_shlibdeps?

because you do want to consider their library dependencies

(these shared libraries might have dependencies on other shared
libraries themselves!)

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4