On 25 May 2006, Goswin von Brederlow uttered the following:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> I would say, off hand, that section 8.2 is for people who want
>> to provide a shared library for other packages, with a stable ABI,
>> and a development package to facilitate linking to their
>> library. There are certain hoops we must jump in order to not break
>> packages whenever the share library package source changes.
>
> I agree with "section 8.2 is for people who want to provide a shared
> library for other packages" but not the rest. As soon as you have a
> cross source package dependency you will have upgrade problems if
> the shared library is not in a shared library package that follows
> 8.2. The big fat state reason why there is an 8.2.
Umm, cross source package dependencies are not supported. The
only such packages currently are all maintained by me, and yes, they
all tend to be upgraded in lock step.
>> I could add a subdir, and play with /etc/ld.so.conf in the
>> maintainer scripts -- and deviate us from other distributions --
>> but to what end? How does it benefit the users if the libraries in
>> question all live in /usr/lib rather than /usr/lib/setools ?
>
> Usualy that is done with rpath, as ugly as that is. Modifying
> /etc/ld.so.conf is never done. Setting LD_LIBRARY_PATH is another
> option as is using the full path in dlopen (though that is usualy
> only used on plugins).
I am not dlopening these shared object. As to rpath, what is
the rationale? Why must I do this, since the packaging already give
package maintainers a strong hint that they should not link to these
libraries?
--
Give your very best today. Heaven knows it's little enough.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
