Re: BBVERSIONS

[Chris Larson <clarson@kergoth.com>]

On Tue, Mar 23, 2010 at 8:57 AM, Martin Jansa <martin.jansa@gmail.com>wrote:

> On Tue, Mar 23, 2010 at 08:41:14AM -0700, Chris Larson wrote:
> > I also agreed that it's nicer to duplicate a tiny amount of metadata than
> to
> > have a giant file full of overrides, but with BBVERSIONS, you could keep
> > every minor version of a given major version around.  Keep one recipe per
> > major version, just keep all the minor versions around.  It really
> doesn't
> > take that long to fire off a loop that builds all variants, I have a
> script
> > for it - bitbake sets a variable that lists them all, but like I said in
> the
> > start of the thread, personally, I'd rather see the versions available,
> and
> > relatively easy to fix if they break, than either remove them entirely or
> > let their recipes bitrot.  That's my personal opinion, of course, I'm
> sure
> > others disagree.. but I do think this feature could be useful, even if we
> > don't keep every version around, since it makes it easier to share
> metadata
> > across multiple versions without having to create a pile of extra .inc's.
> >  foo.inc and foo_ver.bb is great, foo_1.x.inc, etc gets messy fast.
>
> Yeah loop is easy for build test, but it doesn't say anything about how
> it works on device.
>
> From my POV existance of foo_1.3.2.bb signs that at least someone used
> it in some point in time on some device and it was usefull for him, but
> existance of 1.3.2 in some version range doesn't show which minor was
> tested/used and which was added automagically because of BBVERSIONS
> existence.
>
> Again it's also my limited imagination and if it's used only for recipes
> which existed before in OE and were almost the same, it can save few files
> which is nice.
>
> Not sure how zecke's audit script and resulting cleanup/fix-up for whole
> tree will work when BBVERSIONS extends available versions with some
> vulnerable minor version and nobody will be willing to backport security
> patch from latest.
>
> Just my 2c.


Fair enough, there are valid concerns here, though I think some exist with
or without the bbversions mechanism to a certain extent.  If a minor version
is buildable that isn't patched with the security patch, remove it from the
BBVERSIONS variable.  Not that different from what you'd do today, just with
less individual recipes.  I'm not proposing that we sit down and turn every
recipe into something like what I'm playing with with nano, where you can
build any version that exists, this is just a proof of concept, to
experiment with the new possibilities for structuring of recipes.  I expect
in the real world we'd start by using it to consolidate some metadata, as
you mention, and add only versions which we already have, or have tested.
 Do you think the feature would be useful in this way?

Of course, ideally, we'd set up more testing of things on the target with an
automated testing system of some sort, to make it easier to confirm that we
haven't broken things in other versions and other architectures (and this is
a concern today too).

Are there any concerns about this feature existing actually being a problem,
in that it will encourage people to start using it, or should we get it into
master and see how it goes?  We won't be able to really utilize it in OE
until 1.10 releases and we bump our required bitbake to 1.10 anyway, which
is why I'm doing the testing and experimentation outside it for now.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics