Re: BBVERSIONS

[Chris Larson <clarson@kergoth.com>]

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

> On Mon, Mar 22, 2010 at 03:26:53PM -0700, Chris Larson wrote:
> > Greetings all,
> >
> > Thoughts? Questions? Concerns?  I've been wondering if this is really
> > worthwhile, but I think it is.  I think there is value in keeping old
> > versions around, but this allows us to avoid cluttering up the repository
> as
> > much, and makes it so that one change to a recipe can affect all the
> > versions in that range by default, or all versions, rather than just the
> one
> > version you tested.  Of course, ideally you'd test all versions, but
> that's
> > the case today too, its just that now our recipes get bitrotted instead.
> >  Personally, I'd rather see the old version content continue to be
> brought
> > forward by default, and if it fails to build with that, we fix it, but
> it's
> > easier to fix a build than to unclutter the repository.
> >
> > I'm hoping to get some input on this :)
>
> For me it seems easier to read shared stuff in .inc and then multiple
> files with just include on .inc and checksums. Sometimes with additional
> patch or some fix only for particular version, instead of one a bit
> longer file with OVERRIDES.
>
> But maybe it's just lack of imagination on my side.
>
> Also as I stated in some other thread, I think it's usefull to have one
> version
> of each major version which was in OE (probably latest from each range
> you have in nano.bb example), because to test 5 version at least if
> patches apply cleanly and it builds ok, is much faster than 42 version
> from example.
>

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.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics