Hi all,
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:
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.
1a) This compat package must be successfully build before a build of
the update causing the change may be requested.
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. After the warning one must wait 7 days minimum before the
new version may be build.
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.
2a) If there is:
-a small incompatible API change which can _not_ create silent (not
detected by the compiler) breakage, and
-other packages using the package can easily be fixed to compile and
run with the new version, then
The quick and dirty method may also be used. An example of this would
be a function getting an additional parameter which can be set to 0 to
get the old behaviour. In this case however other packagers must be
warned and the warning must include a description what changes are
necessary and howto make these changes.
2b) When a compat-xxx-devel package is created this package must
be parallel installable with the real -devel package. In cases where
this is very hard to achieve in a good way an exception to this rule
may be made by the reviewer.
3) The quick and dirty method consists of:
* renaming the spec file and "Name: " field to:
compat-<oldname><majorversion>
Where <majorversion> is the for the soname relevant
part of the version without the dots. For example if a new SDL 1.3
would be released then the EVR of the compat package would be
compat-SDL12-1.2.10-1, and thus _not_ compat-SDL1210-1.2.10-1
because the .10 is not relevant for the soname since SDL-1.2.0 had
the same soname.
* Remove the -devel subpackage
* Add the files from %files devel to %files with %exclude in front.
* Add a Changelog entry describing the changes and the reason for this.
* Create a Review request for this and approve it yourself in order to
keep Chris' scripts happy. This also makes other other FE contributers
aware of what your doing through the review-list.
* Import, request branches etc.
Well thats it I hope verybody likes it and FESco can vote on this
sometime soon :) Notice that I have no direct interest in this, it is
just something I've been thinking about after the directfb discussion.
Regards,
Hans
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
