[oe] BBVERSIONS

[Martin Jansa]

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.

Regards,
-- 
uin:136542059                jid:Martin.Jansa at gmail.com
Jansa Martin                 sip:jamasip at voip.wengo.fr 
JaMa