soname change policy proposal

[Hans de Goede]

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.
> 

Did you even bother to read the entire proposal? Thats _exactly_ what
the quick and dirty compat rule is for and without these rules we have
things like a directfb update causing yum update to fail for days in a
row, locking out most users of those o so vital security updates you're
defending over here! Also if such a security update is indeed done
without any rule on howto properly handle / coordinate the soname change
yum update will simply refuse to update, so the fix won't reach its
intended audience (the end users).

I do agree with you that "you can quickly end up with dozens of compat
packages for the same library if it is _really_ rapidly changing"
although that can easily be solved simply by:
1) asking maintainers to rebuild against the newest release
2) when releasing a new compat package remove all of the older compat
 package under the condition that no other package requires that older
 compat packages.

And have you ever considered that if upstream changes the soname every
few days that upstream then is seriously borked and you thus have a much
bigger problem?

Regards,

Hans