[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

soname change policy proposal



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]