soname change policy proposal

[Ville Skyttä]

On Tue, 2006-06-27 at 09:42 +0200, Hans de Goede wrote:

> I've been thinking about this for a while and I think its time for a 
> brain dump, so here is a first shot at a soname change policy:

My opinions/comments below:

0) Try hard to avoid incompatible upgrades within non-devel distro
branches.  Note: this is not limited to library sonames, but to all
packages!  If you're convinced that it doesn't make sense in the case at
hand, then:

> 1b) If an update causing a soname change will only be build for devel
>   a compat package is not mandatory. In this case however other packagers
>   must be warned, with the warning containing a way for them to get the
>   new version.

This warning must be posted in public, to the fedora-maintainers mailing
list.

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

> 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.  Shipping compat-*-devel is
discouraged, and in addition to the above, may be done only if there are
existing packages in FC+FE which will actually have to use it (where
"have to" expands to "a simple rebuild against the new version is not
enough").

>   -other packages using the package can easily be fixed to compile and
>    run with the new version, then

Enumerating "other packages" is not possible.

> 2b) [...]

2c) Only one compat-foo per foo by default, no automatic compat-foo10,
compat-foo11, compat-foo12 proliferation.  More than one compat-foo<X>
per released distro branch requires FESCO approval.

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

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

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

> Notice that I have no direct interest in this,

Everyone does... ;)