soname change policy proposal

[Kevin Kofler]

Hans de Goede <j.w.r.degoede at ...> writes:
> 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!

There's an easy fix for that:
yum install apt
This yum misdesign is the problem, not the soname changes.

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

The update will be done (doable at least, see above paragraph) a few hours 
later when the reverse dependencies have been rebuilt. Compare this to the 
compat packages situation where packages can be running against the vulnerable 
version for months with nobody noticing (no "broken dependencies" report, for 
example). Also, I want vulnerable packages the h*ll OFF my systems, not put in 
a compat library!

I also generally don't want to have 2+ versions of each library cluttering my 
hard disk, I want the packages to be updated to work with the latest, and 
compat packages encourage exactly the opposite (and if I hit the hopefully 
short window where the package is not rebuilt, instead of the library being 
held back by apt-rpm, I'll get a compat library installed which will become 
unnecessary only hours later, what a waste).

As for packages outside of Extras, I don't see why they shouldn't be rebuilt 
too if Extras changes. As a packager of a few unofficial RPMs (which need some 
cleanups before I can consider submitting them to Extras), I'll definitely 
rebuild my RPMs as quickly as possible if a soname change in Extras requires 
it, I don't see why Extras should be forced to provide compat libraries just to 
allow me or others to be lazy.

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

It can be solved much MORE simply by not introducing the compat library clutter 
in the first place and just doing 1).

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

That's not something Extras can fix, so it's pointless to discuss here.

         Kevin Kofler