Changing kernel API / Breaking VirtualBox - update criteria violation?

Matthew Garrett mjg at redhat.com
Tue Nov 22 19:53:12 UTC 2011


On Tue, Nov 22, 2011 at 11:44:59AM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 22, 2011 at 06:57:30PM +0000, Matthew Garrett wrote:
> > So just to be clear on this, you believe that if a user is relying on 
> > byte 0x9e0 of /bin/ls to be 0xdf on x86_64, then that is something that 
> > would have to be considered under the update policy?
> > 
> Yes.  Consideration ie: thinking.  Making an informed judgement is what the
> policy requires.  Do you have to spend long, sleepless nights tossing and
> turning and pulling out your hair over that one user out of our supposed
> million?  No.  You can quickly evaluate and say that this is one user using,
> as we're agreed on, an unsupported feature of our package and therefore
> we're going to push a bugfix update anyway.  As I wrote in my reply to
> davej, this can even be a decision that is applied in an ongoing manner
> (What is the exception section of the policy, anyway but such decisions made
> and applied at a more global level).

Ok. I don't believe that this is the intended interpretation of the 
update policy. It was never our intention to discourage changes that are 
outside the scope of the supported interface of the package.

> Here's a counter example of equally hypothetical proportions -- let's say
> that you believe every user of Fedora 16 to rely on byte 0x9e0 of /bin/ls to
> be 0xdf and that if that is changed Fedora 16 will need to be rebooted from
> a rescue cd in order to be restored.  Would you say that that is something
> that would not have to be considered under the update policy?

That would require packages within Fedora to be dependent upon that 
behaviour, and so the update should be prevented because it would break 
other packages that we ship. If we've inappropriately relied upon 
unspecified behaviour of a package then that's something that we have to 
deal with. If a user has inappropriately relied upon unspecified 
behaviour of a package then that's something the user has to deal with.

> > This case requires no clarification.
> > 
> The fact that you and I are continuing to argue about this despite the fact
> that we agree on the desired outcome would suggest otherwise.

No. You're simply interpreting things incorrectly.

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


More information about the devel mailing list