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... ;) -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
