Hi,
On Tue, Jun 27, 2006 at 09:42:03AM +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:
I agree with Ville to prepend this with the (soft) requirement to try
to remain ABI compatible within a distribution.
> 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.
I had a similar suggestion some time back on this list, where I tried
to persuade to use compat-like packages from the beginning, so that
there is no need to rebuild new old-packages and rereview them, and
also no need to sync compat vs new packages, coordinate rebuilds of
all dependent packages and the like. It is also both backward and
forward compatible: Simply subpackage the library components in
libfoo<somajor> packages like Debian/Mandriva/ATrpms are doing.
The libfoo<somajor>s are already your compat packages, when a new bump
happens libfoo<somajor+1> simply appears in the repo next to the to be
outphased libfoo<somajor>. Applications can be rebuilt against the new
foo at their own pace. No review of the compat-becoming
libfoo<somajor> is neccessary, since it hasn't changed, not only in
theory, but it is still the same well-known binary with the same rpm
metadata. No subtle rpm meta-obsoletes due to Provides: of some common
resource (see Rex' comment).
The only drawback: Your system doesn't cater for old and unused
libfoo<soname-N>s. But that's fixable by tagging the packages. For
example ATrpms uses Provides: shared-library-package, so all such
compat packages can be found with a simple rpm -q --whatprovides
shared-library-package, for example:
# rpm -q --whatprovides shared-library-package
libsrs_alt1-1.0-2_rc1.rhfc5.at
libbeecrypt6-4.1.2-9.2_11.rhfc5.at
libgcrypt11-1.2.2-11.rhfc5.at
libspf2_2-1.2.5-4.rhfc5.at
libgcrypt11-1.2.2-11.rhfc5.at
libdirect-0.9_24-0.9.24-8.rhfc5.at
libfusion-0.9_24-0.9.24-8.rhfc5.at
Therefore one could easily implement a "package garbage
collector". The poor man's implementation would look like
rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' --whatprovides shared-library-package | xargs -l1 rpm -e 2> /dev/null
[As a side-effect you get multi-repo combinations working better,
since repos are using different libfoo<soname+N>. This isn't an
argument for Fedora Core/Extras, but it was the motivation for
ATrpms to use that method. Still given the size of Fedora Extras
having larger time windows for libfoo transitions of dependent
packages is a good thing and comparable to the not-synced
upgrading of libfoo<soname> in different repos, e.g. in Fedora
Core/Extras semantics: no need for alarms at fedora-maintainers
etc.]
This scheme works very nice. The question I still have is whether to
only apply it to a very selected set of packages known from the past
to aggressively bump sonames, or whether it makes sense to have this
as a general guideline to avoid ever getting into such a trap again.
I guess in order to find out how well this scheme works the first
model could be tried out on the problematic packages and depending on
success/failure it could be extended to further packages.
--
Axel.Thimm at ATrpms.net
Attachment:
pgp3eJ4hYehrh.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
