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

Re: Packages violating policy 8.2



On 22 May 2006, Goswin von Brederlow outgrape:

> Manoj Srivastava <srivasta@debian.org> writes:
>
>> On 19 May 2006, Goswin von Brederlow outgrape:
>>
>> 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.
>
> I think that Policy 8.2 is fully applicable to your package then. It
> is a MUST directive so your unwillingness to allow multiple versions
> of your library to coexist does not affect the violation.

        I beg to differ. There is a rationale for the policy section:
 that in general, shared library packages  are meant to be long lived,
 and that packages linking to older versions of the library are
 supported.  The policy then goes on to define how you achieve that.

        In this particular case, that is not supported, or even
 possible: SELinux packages move in lock step, and older versions of
 libraries and policy, and related tools and utilities would not work
 when the base packages are installed, in most cases.

> Following 8.2 you only have 2 choices: Split the package or provide
> only static libaries and live with the wasted space. Otherwise the
> packages is RC buggy.

        May I ask what is the underlying rationale for this judgement?
 In what way do you think splitting the package would work? Why is
 facilitating private packages for people who are working with SELinux
 a bad thing, when people who actually build and use these packages
 are aware of the current state of flux of SELinux?

        Remember the bit about foolish consistency for the sake of
 consistency and hobgoblins. I have reviewed this issue, and have
 decided tht the current single package approach is best, given the
 circumstances.

        msnoj
-- 
Let us endeavor so to live that when we come to die even the
undertaker will be sorry.  -- Maek Twain, "Pudd'nhead Wilson's
Calendar"
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: