On 22 May 2006, Goswin von Brederlow stated:
> Manoj Srivastava <[EMAIL PROTECTED]> 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
package.
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.
manoj
--
Machine-Independent, adj.: Does not run on any existing machine.
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]
