Changing kernel API / Breaking VirtualBox - update criteria violation?

Matthew Garrett mjg59 at srcf.ucam.org
Tue Nov 22 18:28:06 UTC 2011


On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 22, 2011 at 05:12:12PM +0000, Matthew Garrett wrote:
> > I don't know how much clearer I can make this. The update policy applies
> > to the supported ABI of the package. For instance, if I have an 
> > application that depends on byte 0x9e0 of /bin/ls being 0xdf and an 
> > update breaks that, that's not a relevant consideration for the update 
> > policy. The kernel module interface is not a supported ABI in Fedora. 
> > It's simply not a relevant consideration for the update policy.
> > 
> I don't know how much clearer I can make this -- The updates policy applies
> to more than the "supported ABI of a package".  For instance, if you have an
> application that dependds on /bin/ls printing "?" when it encounters
> a filename with a byte that cannot be decoded in the current locale and it
> starts printing \001 instead, that is a relevant consideration according to
> the updates policy.

Consuming the output of ls is a supported way to use ls. Building third 
party modules is not a supported way to use the kernel.

> > The policy is fine as is. The problem is your overreaching definition of 
> > ABI. We could make it explicit that the module interface isn't an 
> > exported ABI by modifying the loader so that third-party modules simply 
> > can't be loaded at all and then this clearly wouldn't be an issue, but I 
> > don't think anyone benefits from us doing that.
> 
> The definition of ABI is not at issue.  The reach of the updates policy
> itself is.  If I'm understanding you correctly you think the updates policy
> applies to a much more limited scope of changes than I do.  I would suggest
> that that is an indication that the updates policy needs to be reworded in
> at least certain places so as to more clearly illustrate whether it has
> a broad scope (in which things like ABI are examples of criteria for
> deciding not to issue an update) or limited scope (in which ABI is one of
> the specific criteria for decding to withhold an update.)

It's clear that if we disabled the ability to build third party modules 
at all that the ability to use third party modules would be entirely 
irrelevant and clearly not a consideration. So just pretend that we've 
done that.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list