soname change policy proposal

[Hans de Goede]

Ville Skyttä wrote:
> On Tue, 2006-06-27 at 09:42 +0200, Hans de Goede wrote:
> 
>>   * Create a Review request for this and approve it yourself
> 
> -1, all new packages need to go through the usual review process, and
> compat-foo is a new package, even if it rises from the ashes and is
> reintroduced in a new distro branch when it existed for earlier ones but
> not yet for the new.
> 

Erm, if you mandate this then many packages may start to suffer from
bitrot unfortunatly there are quite a few packages which _always_ bump
the .soname each (minor) release. Directfb is but one example of this,
the whole idea behind this quick 'n dirty compat rules is to make it
easier for people todo compat packages, thus avoiding breakage as we;ve
seen in the past.

Maybe the plan I gave howto create a quick and dirty compat package
should be ammended to say that the changes listed there are the only
changes allowed?

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!

>> Well thats it I hope verybody likes it and FESco can vote on this 
>> sometime soon :)
> 
> Open issues:
> 
> - Q: How do compat-<foo> become purged on distro upgrades?  A: New
> distros should under normal circumstances start with no compat-*
> packages and packages that did have compat-* ones in earlier distros
> must have appropriately versioned "Obsoletes: compat-foo<major> < V-R"
> for each such compat (usually only one).  Ditto for
> devel/compat-foo-devel.  If an obsoleted compat-foo has to be
> reintroduced to the new branch, the corresponding Obsoletes needs to be
> dropped at that point, and an update pushed for the new main package at
> the same time as the new compat package.
> 

EWONTFIX, we have this issue with core provided compat-xxxx packages
already. This can be best handled by anaconda at update time, either way
I do _not_ want to have this problem tagged ontop of this policy, its
IMHO a seperate problem.

> - Should compat-foo<major> = $ver-$rel have "Provides: foo = $ver-$rel"?
> What about "Provides: compat-foo = $ver-$rel"?  If not, breakage is
> likely if packages need to use something else than the autogenerated
> library/soname dependency (eg. for versioning not adequately
> accomplished through sonames).  What about compat-foo<major>-devel <->
> "Provides: foo-devel = $ver-$rel" and "Provides: compat-foo-devel =
> $ver-$rel"?  There have been some depsolver issues in the past with
> setups like this, dunno if the world has been fixed since.
> 

I think that provides like this will cause more breakage then they fix.

Thanks for your input & Regards,

Hans