On Wed, 19 Jan 2011 17:58:04 +0100, Loïc Minier <loic.min...@linaro.org> wrote: > That's exactly my point: have the next version of the code try to do > the right thing. Maybe I actually have broken expectations: I expect > l-i-t would reject hwpacks with unknown fields. That's the failure > I'm trying to avoid if we know we're going to introduce a linux_image > field and that it can be safely ignored. > > It's a bit like when Debian introduced Breaks, by adding support to > dpkg to simply treat the field in a dumb way, and then adding full > support the next cycle, as to allow using old dpkg for upgrades.
Good example. We can certainly do this, we just need to have a plan like they did. We can't just add every field that we think we may one day want and ignore them all, as that will often lead to a bad user experience when we use the field, or having to have a format bump later anyway before we can use it. An illustration of what I mean: if we add linux_image and ignore it, and then use it within Android hwpacks, someone with the old code will try and use one of those new hwpacks, and get an unbootable Android image. When that happens someone will say "we should have the tool warn people when it can't do what they ask", which we could have done now with a format bump, or by having a more complete plan than "ignore the field". The crux of my point is that every field we add has to have clear semantics. It's rather an obvious statement, but one we should stick to. Thanks, James _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
