KDE vs. GNOME on F10

Adam Williamson awilliam at redhat.com
Wed Aug 5 19:11:40 UTC 2009


On Wed, 2009-08-05 at 11:58 -0700, Toshio Kuratomi wrote:
> On 08/05/2009 11:47 AM, Adam Williamson wrote:
> > And maintainers can choose whether or not they
> > want to take on the work of shipping updates in the adventurous
> > repository.
> 
> How does this work?  It would seem that the adventurous repository would
> be mandatory as something that changes ABI would require other packages
> to be rebuilt.

In the Mandriva system, ABI-breaking updates in /backports are
discouraged by policy. When it happens, obviously you have to provide
updates for all dependencies in /backports, too.

Neither of the examples in question really breaks many public ABIs,
though, AFAIK. GTK+ version bumps don't break the ABI, we don't rebuild
seven thousand packages each time GTK+ gets updated (it's still on the
2.0 ABI). Most KDE / GNOME breakage with new releases is 'internal', I
think - so if you're updating all of KDE/GNOME anyway, the API/ABI
breakage isn't a problem.

> Also, having the expectation that the other repository is for security
> updates doesn't address the problem of a security release breaking ABI.

That's rather unlikely (well, except in oddball cases like Firefox /
XULRunner), but sure it does - if a security update cannot be done in
any way other than by breaking API/ABI, you ship rebuilds of all
dependent packages as official updates in the stable update repository.
That's how we'd handle it at present anyway. The normal policy is you do
the minimum possible amount of changes to address vital problems, but
you do _have_ to fix them, even if the 'minimum possible amount of
changes' involves rebuilding a dozen packages. This is how all
conventionally updated distros work, AFAIK (including for e.g. RHEL -
they wouldn't just leave a security hole unpatched because they had to
break an API/ABI to fix it ...)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net




More information about the devel mailing list