[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 stated:

> Manoj Srivastava <srivasta@debian.org> writes:
>> On 22 May 2006, Goswin von Brederlow outgrape:
>>> 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:
> And if it where optional then it would read SHOULD. Or what is the
> difference between MUST and SHOULD if you can jsut choose to ignore
> both?

        The section in question is about shared library packages, but
 I am not actually creating a shared library package. Perhaps this
 needs clarification in policy.

>>> 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?
> My motivation is that not following 8.2 will make it impossible to
> convert the package to multiarch. For the rational of 8.2 itself you
> have to read policy and ask the people who wrote it. But I think it
> is pretty clear from the text: to be able to install multiple
> versions of the library for smooth upgrades.

        That person could well have been me, though I can't say I
 recall writing that.  But the intent of the section is for shared
 library packages, and  as such setools is not a shared library

        I'll be happy to discuss what I need to do about multi-arch.

>> In what way do you think splitting the package would work? Why is

> The same way it works for each and every other library package that
> is split in Debian.

        But I have no intention of supporting multiple versions of the
 libraries for setools, like I do for my other shared library packages
 which are indeed split up.

>> 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?
> It isn't a bad thing but you aren't doing it "right" (right as laid
> out in policy).

        Policy is not all infallible, not does it always apply. I
 think packages shipping libraries with relocatable code which
 explicitly do not support backwards compatibility nor multiple
 versions for the library in question, and do not split out library or
 -dev packages, are not covered by the rules designed for shared
 library packages.

Machine-Independent, adj.: Does not run on any existing machine.
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: