Re: Packages violating policy 8.2
Manoj Srivastava <srivasta@debian.org> writes:
> 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.
To me it sounds like you are. You provide a shared object file in a public
place so other people can link their binaries against it. What else is
a shared library? Does it matter if no package in Debian uses it but
only other people? I think not. If you intention is to let others link
against it then it is a shared library by all means.
On a version upgrade the people that have their binaries linked
against your lib will be unable to upgarde without removing those
binaries first. The will have to work without them or with a chroot to
even recompile for the new lib. Think about that.
>>>> 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.
If you say those libraries are not public then policy 10.2 would seem
to apply:
Policy 10.2:
| Shared object files (often .so files) that are not public libraries,
| that is, they are not meant to be linked to by third party executables
| (binaries of other packages), should be installed in subdirectories of
| the /usr/lib directory. Such files are exempt from the rules that
| govern ordinary shared libraries, except that they must not be
| installed executable and should be stripped.
Since you want to support linking by third party executables you don't
quite fit the description of not public library. But well, lets keep
one eye closed. Reading on you are violating a SHOULD directive.
I agree that binary packages with *.so.* files can well fall under
10.2. Do you think your package fully does?
> 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
It might be that that distinction is just missing from policy. So far
it only has the two options: public shared library and not public
library. Imho any third party linking against the library would mean
it has to be (made) public.
Feel free to draft a clarification to policy but I think 8.2 and 10.2
do cover all cases well enough.
MfG
Goswin
Reply to: