[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages violating policy 8.2

Manoj Srivastava <srivasta@debian.org> writes:

>  On 25 May 2006, Goswin von Brederlow uttered the following:
>> Manoj Srivastava <srivasta@debian.org> 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.


Reply to: