Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 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.
>From your previous mail:
| setools is in the list, and contains libraries that it uses
| itself, but does not break it up into multiple installed
| packages. Setools is moving rapidly rnough that I do not intend to
| support multiple versions of the libraries until things stabilize a
| bit.
|
| However, people do build binaries against these libraries, and
| even have private packages, and I intend to support that.
What is that if not a cross source package dependency?
>>> 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?
Well, you are one of the authors of policy, you tell us the rational
behind 10.2.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
