Re: Packages violating policy 8.2
On 23 May 2006, Goswin von Brederlow stated:
> 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.
It is a shared library, and you are free to link with it --
but as a developer you must realize that your package may break on
upgrade, since there is no shared library package, just a single
combined setools package.
With that caveat, this is a convenience for people who are
working on setools.
> 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.
I am. So if I build custom packages against these libraries,
upgrades fail to install -- and then I force install and
rebuild at a time of my chosing.
Works quite well for me.
>>>>> 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.
Err, those a plugins, and one generally dlopens them, or
otherwise manipulates the loader. It certainly does not apply.
> 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 am not supporting linking by "third party executables". I
am, however, allowing people who recognize the lack to backward
compatibility to help out with the development of SELinux.
> I agree that binary packages with *.so.* files can well fall under
> 10.2. Do you think your package fully does?
Nope.
>> 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.
Policy speaks of only two cases:
a) A shared library, supported for longe term linking, where a shared
library package is created and kept around so that people can link
with the library, and where multiple versions of the library stay
around, and are not removed on new upstream.
b) private share objects used as plugins that are opened with dlopen
None of these cases apply here.
> Feel free to draft a clarification to policy but I think 8.2 and
> 10.2 do cover all cases well enough.
I am not sure the sections need clarification, inasmuch as
they do not really apply to setools. I might clarify that 8.2 is
meant for packages that provide shared libraries for general use by
other package developers, and it implies a certain level of assurance
that the rug shall not be yanked out from under the aforementioned
developers feet.
manoj
--
"An entire fraternity of strapping Wall-Street-bound youth. Hell -
this is going to be a blood bath!" -- Post Bros. Comics
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: