soname change policy proposal

[Hans de Goede]

Jeremy Katz wrote:
> On Tue, 2006-06-27 at 13:59 +0200, Hans de Goede wrote:
>> please reread the little howto I wrote, then you'll that the package
>> is effectivly unchanged, just renamed and stripped of its -develo
>> subpackage. I just realized that if its a mixed lib and binary package
>> it should actually be stripped of everything except the libs and %doc.
>> So maybe the howto needs some rewording, but as said the idea is that
>> this isn't a _new_ package is just a rename of an exisiting one! 
> 
> ... in that case, it should be quick and easy for the review to
> happen :-)
> 
> Jeremy
> 

Its unnescesarry pain for the maintainer and an unnescesarry burden on
the Review process which is already overloaded as is.

Also see what Kevin Kofler wrote:
> Hans de Goede <j.w.r.degoede at ...> writes:
>> 1) When a package update would cause an soname change then a compat
>>   package with the old libraries must be provided for all release repos,
>>   that is for all repos except devel.
>
> IMHO this is ridiculous. Even Core doesn't follow such a strict
policy. This is
> going to hinder critical security upgrades for packages such as
SeaMonkey, and
> also leave rapidly-changing libraries (which are the ones needing version
> upgrades the most!) stale at old versions (and you can quickly end up
with
> dozens of compat packages for the same library if it is _really_ rapidly
> changing). I think the current policy of simply getting packages
rebuilt if a
> soname changes (which is also what is done when Core upgrades a
soname) works
> well.
>


So he thinks that even mandating a compat package is a bad idea, I'm
tryign to find some middle ground here.

Regards,

Hans