On 08/05/2009 12:11 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 11:58 -0700, Toshio Kuratomi wrote:
> 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),
heh, the exact case I was thinking of :-)
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 ...)
Sure, this is comparable to the present situation. But it doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't going to be updated for F10 since the maintainers don't want to do
this and the policy wouldn't require it)
* It doesn't solve the follow-on issue of things being different between
major Fedora components (since gnome maintainers don't want to
participate but kde maintainers do)
* It makes things more complex (for instance, we would have to build
packages against multiple repository sets -- ie: [F12-release +
F12-updates-security] [F12-release + F12-updates-security +
F12-updates-adventurous] since there could be incompatibilities between
the packages in updates-security and updates-adventurous.).
* It makes more work for rel-eng to prepare and push the extra repos.
-Toshio