soname change policy proposal

[Hans de Goede]

Hi,

I think you are trying to make this failproof in a totally over the top
way. The end result being that nobody will do a soname bump in the
non-devel branch possible keeping nice packages out non devel branches
because they need a newer version and/or keeping bugs in the non-devel
branch because releasing the bugfix version would require the maintainer
todo some kinda big and long ceremonial dance.

I wrote this with cases like directfb in mind where upstream changes the
soname every!  release. The whole idea behind my policy proposal was to
have a sane and reasonably* safe policy, while at the same timing not
making it nearly impossible for maintainers to actually do an soname change.

*100% safe does not exist, get that stupid notion of 100% safe out of
your head please

As I also wrote a API change which causes non trivial to fix build
errors, makes it mandatory to add a -devel sub package to the compat
package, so in the security problem case the fixed package can build
against this -compat-devel package.

But I've learned from your and other reactions that there is appearantly
 no support on the list for a balanced soname policy. With the end
result being that there probably isn't going to be any policy at all.

I must say I'm disappointed in the lack of the ability to see the
balance of things here on the list.

Because of this will probably be my last post in this thread.

Regards,

Hans




Michael Schwendt wrote:
> On Tue, 27 Jun 2006 11:55:45 +0300, Ville Skyttä wrote:
> 
>>>  After the warning one must wait 7 days minimum before the
>>>   new version may be build.
>> 7 days is too much.  If Core devel is not in the post-last-testX freeze
>> before the next release, 1 day is enough.  If Core devel is in that
>> freeze, rules for released distro branches apply to devel too.
>> Example: according to the current
>> http://fedoraproject.org/wiki/Core/Schedule, the final post-last-testX
>> freeze would be 23 Aug - 27 Sep.
>>
>> For released branches, we assume that a smoothly working compat-foo has
>> been already created before the incompatible upgrade is pushed and it
>> has stayed in a review for a little while anyway.  So there's no wait
>> period, but the notice must be posted to the fedora-maintainers list
>> when the new compat package is posted for review, and the review bug
>> number is included in that notice.
> 
> It is not that easy.
> 
> For every scenario in which a packager starts working on a compat-fooX
> package for a _release branch_ of a dist, much more must happen prior to
> shipping the package.
> 
> First of all, and provided that the packager notices the SONAME change (or
> ABI/API change) at all, it _must_ be verified that existing software in
> the release branch can still be (re-)built with either compat-fooX-devel
> or the new foo-devel. This step is mandatory. It requires review, testing,
> and approval.
> 
> I see phrases like "quick and dirty" and would prefer if it were called
> "painstakinly and safe" instead. Any API break in a release branch may
> prevent the next security fix from being built quickly and painlessly.
> 
> Further, packagers, especially library packagers, ought to become familiar
> with what in the distribution depends on them. I'm not convinced that
> maintainers-list is the right forum where to address package owners and
> where to warn about ABI/API breakage.  I'd rather see packagers use
> bugzilla or private mail to announce and talk about a change in SONAMEs
> before agreeing on introducing the changes. There ought to be coordination
> and collaboration. Application packagers could be the reviewers of library
> packagers' review requests.
> 
>>> 2) When a compat package must be created there are 2 possible scenarios.
>>>   When the soname is changed the ABI is changed, however sometimes the
>>>   API is not changed or kept compatible. When the API is not changed then
>>>   the compat package must not come with a -devel subpackage and the quick
>>>   and dirty method described below may be used. When the API is changed
>>>   the compat package is concidered a new package and must go through the
>>>   review process as usual, in this case the compat-package must come with
>>>   a -devel subpackage.
>> All compat-* need to go through a review.
> 
> But of course!
> 
>