[csw-maintainers] An idea for a shared libraries policy

[Maciej (Matchek) Blizinski]

No dia 7 de Outubro de 2010 06:55, Philip Brown <phil at bolthole.com> escreveu:
> On Wed, Oct 6, 2010 at 9:42 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> (Phil wrote)
>>> I think you might do well to go with my original theory, slightly expanded:
>>>
>>> Unless you find a shared object, of filename "lib*.so*", AND it has a
>>> "SONAME", AND that name has a double-numeric rev  (eg:
>>> libfoo.so.#.#), then you should just leave it alone.
>>
>> I understand and I agree with the first two criteria: It makes sense
>> to separate the library out, if it is named lib*.so*, and has a
>> SONAME.  I don't get the bit with the double-numeric versions.  What
>> matters is the presence of SONAME, and the contents is a conventional
>> notation, why would any numbers matter?
>>
>
> (I did explain this previously, but I'll repeat myself for this case)

I didn't mean to make you repeat yourself.  I understand the potential
(depending on the approach of developers) implication of declaring "we
change the API frequently" via including the minor version number and
"we offer a stable API" by including the major version only.  This
tendency is clear to me.

What I meant is that the life cycle of an API-wise unstable library
consists of exactly the same phases as the life cycle of a API-wise
stable library:

1. A SONAME appears
2. We decide to distribute it
3. Binaries start linking to it
4. Time passes, new version of the same library comes along
5. Binaries stop linking to it
6. SONAME goes away

Life cycles of SONAMEs might span shorter or longer time frames, but
are otherwise identical.  Therefore, the packaging policy has no
reason to depend on the API change frequency.  In other words, if you
want to retire your SONAME in a clean and easy way, always put it into
a separate package.