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