BBVERSIONS

BBVERSIONS

[Chris Larson]

Greetings all,

I'm emailing about a prototype I threw together of a BBVERSIONS
implementation in BitBake.  This functionality is similar to BBCLASSEXTEND,
but it lists versions, and sets PV rather than doing an inherit.  This
allows you to create one recipe that can build multiple versions of
something.  Either you can do one recipe that can build everything, or you
could (I prefer this) create one recipe for each range of versions which are
built in a given way with a given set of patches.

It helps if you think about an upstream change (which, say, breaks
application of a patch) as being a change going forward.  No one makes a
change assuming it'll be reverted the next release, so it's likely that a
given patch will apply through a set of versions, until another change
breaks it further.  So, metadata and patches is really rarely bound to just
one version, but is instead bound to the series of versions which can be
built in that way and which can have those patches applied.

The version from BBVERSIONS is added to OVERRIDES, to allow for version
specific metadata.  In addition, you can specify a name for the range of
versions, which is also added to OVERRIDES.  As an example, I created a
nano_1.0.0+.bb recipe which builds 1.0.0 through 1.0.6, its BBVERSIONS is
set to 1.0.[0-6].  The BPV variable gets set with the 1.0.0+ value, so it
can be used in the filespath, so the generic files go there, and individual
versions can override further if necessary.

I've been experimenting with a set of files and recipes to build every
version of nano that exists, from 1.0.0 through 2.2.3, with one recipe for
each set of versions.  I'm still investigating to find the optimal workflow
with this, someone else may want just one recipe for all versions, or they
may want to leave it as is, just one recipe per version, but I suspect this
may reduce the number of files duplicated across filespaths amongst versions
which could be grouped together into a single recipe.

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 :)

The bitbake changes: http://github.com/kergoth/BitBake/commits/bbversions
The repository with my experimentations with nano (haven't pushed since I
split the recipe by version range yet): http://gist.github.com/338382
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: BBVERSIONS

[Frans Meulenbroeks]

Chris, while this is a nice idea it conflicts with having checksums in
the recipe, as that makes the recipes unique.
Unless of course there is (or we create) a way to have multiple
checksums in a recipe and pick the one that is for the version we are
building.

Then again I feel it is in most cases better to move forward. E.g. for
your nano example: why would people want to build say nano 1.0.2 if
there is also a working 1.0.6 recipe (or even a 2.2.3 one or whatever
version it is at). I feel it is better to spent time to
fix/improve/add/repair the latest version than spend time fixing old
code.
(generally speaking that is)

Frans.

Re: BBVERSIONS

[Martin Jansa]

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.

Regards,

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

Re: BBVERSIONS

[Holger Hans Peter Freyther]

On Tuesday 23 March 2010 10:32:59 Frans Meulenbroeks wrote:
> Chris, while this is a nice idea it conflicts with having checksums in
> the recipe, as that makes the recipes unique.
> Unless of course there is (or we create) a way to have multiple
> checksums in a recipe and pick the one that is for the version we are
> building.


There is a way or could be a way. For the name= we can use a variable in the 
name (e.g. PV) but have a written out variant for the SRC_URI.

z.

Re: BBVERSIONS

[Frans Meulenbroeks]

2010/3/23 Holger Hans Peter Freyther <holger+oe@freyther.de>:
> On Tuesday 23 March 2010 10:32:59 Frans Meulenbroeks wrote:
>> Chris, while this is a nice idea it conflicts with having checksums in
>> the recipe, as that makes the recipes unique.
>> Unless of course there is (or we create) a way to have multiple
>> checksums in a recipe and pick the one that is for the version we are
>> building.
>
>
> There is a way or could be a way. For the name= we can use a variable in the
> name (e.g. PV) but have a written out variant for the SRC_URI.

That would be cool and also nice to have for current recipes.
When moving a recipe to a new dir you cannot just clip whatever is
generated and paste it into the recipe (especially if the SRC_URI is
in a .inc)
You either need to change the SRC_URI or the generated checksum name.

Re: BBVERSIONS

[Michael Smith]

On Tue, 23 Mar 2010, Frans Meulenbroeks wrote:

> Then again I feel it is in most cases better to move forward. E.g. for
> your nano example: why would people want to build say nano 1.0.2 if
> there is also a working 1.0.6 recipe (or even a 2.2.3 one or whatever
> version it is at). I feel it is better to spent time to
> fix/improve/add/repair the latest version than spend time fixing old
> code.
> (generally speaking that is)

I have a distro I use quite a bit at work, but don't have a lot of time to 
maintain - only a few days a month. I'd like to be able to pull the latest 
.dev from time to time to get kernel updates, xorg, etc. - things that are 
adding new features, support for new hardware, mostly.

Nano is a good example of an application where I'll never, ever want new 
features. :) As long as the version I've pegged keeps building, I'd rather 
not have to think about re-testing the new version, or checking how much 
bigger it got. If the recipe is unsalvageable, fine, kill it and I'll 
spend the couple of hours it takes to re-test - just please don't delete 
recipes only for the sake of tidying.

Mike

Re: BBVERSIONS

[Chris Larson]

On Tue, Mar 23, 2010 at 2:32 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> Chris, while this is a nice idea it conflicts with having checksums in
> the recipe, as that makes the recipes unique.
> Unless of course there is (or we create) a way to have multiple
> checksums in a recipe and pick the one that is for the version we are
> building.
>

See the gist for nano that I linked in the email, I set it up so that works.
 SRC_URI_<pv> flags are automatically transferred to SRC_URI via an
anonymous python function.  I have a checksums.inc that sets them all.

Then again I feel it is in most cases better to move forward. E.g. for
> your nano example: why would people want to build say nano 1.0.2 if
> there is also a working 1.0.6 recipe (or even a 2.2.3 one or whatever
> version it is at). I feel it is better to spent time to
> fix/improve/add/repair the latest version than spend time fixing old
> code.
> (generally speaking that is)
>

Well, in part I agree, and in part I disagree.  This is why I started this
thread about the worth of the feature.  For companies and the like, keeping
old versions around indefinitely is a good thing, and while I know many will
argue that they can keep their recipes for it around, that just encourages
deviation from OE, and believe me, I know how much of a pain it is for a
company to stay in sync with OE :)

Thanks for the comments.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: BBVERSIONS

[Chris Larson]

On Tue, Mar 23, 2010 at 2:50 AM, Holger Hans Peter Freyther <
holger+oe@freyther.de <holger%2Boe@freyther.de>> wrote:

> On Tuesday 23 March 2010 10:32:59 Frans Meulenbroeks wrote:
> > Chris, while this is a nice idea it conflicts with having checksums in
> > the recipe, as that makes the recipes unique.
> > Unless of course there is (or we create) a way to have multiple
> > checksums in a recipe and pick the one that is for the version we are
> > building.
>
>
> There is a way or could be a way. For the name= we can use a variable in
> the
> name (e.g. PV) but have a written out variant for the SRC_URI.
>


Good idea, didn't think about using the version as the name or part of it,
that could alleviate the need for the anonymous python snippet I'm using at
the moment.  (Aside: it would be nice if you could set a flag on an override
variable (FOO_arm) and have that flag be pulled over to the main variable
(FOO) at override collapse time, but BitBake does not do it today).
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: BBVERSIONS

[Chris Larson]

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

Re: BBVERSIONS

[Chris Larson]

Just created a proper github project for my nano experimentations, and
pushed the current incarnation (slightly messier than it needs to be, since
I'm still experimenting with different ways of structuring it).
http://github.com/kergoth/Nano-OE/tree/master/recipes/nano/.

On Mon, Mar 22, 2010 at 3:26 PM, Chris Larson <clarson@kergoth.com> wrote:

> Greetings all,
>
> I'm emailing about a prototype I threw together of a BBVERSIONS
> implementation in BitBake.  This functionality is similar to BBCLASSEXTEND,
> but it lists versions, and sets PV rather than doing an inherit.  This
> allows you to create one recipe that can build multiple versions of
> something.  Either you can do one recipe that can build everything, or you
> could (I prefer this) create one recipe for each range of versions which are
> built in a given way with a given set of patches.
>
> It helps if you think about an upstream change (which, say, breaks
> application of a patch) as being a change going forward.  No one makes a
> change assuming it'll be reverted the next release, so it's likely that a
> given patch will apply through a set of versions, until another change
> breaks it further.  So, metadata and patches is really rarely bound to just
> one version, but is instead bound to the series of versions which can be
> built in that way and which can have those patches applied.
>
> The version from BBVERSIONS is added to OVERRIDES, to allow for version
> specific metadata.  In addition, you can specify a name for the range of
> versions, which is also added to OVERRIDES.  As an example, I created a
> nano_1.0.0+.bb recipe which builds 1.0.0 through 1.0.6, its BBVERSIONS is
> set to 1.0.[0-6].  The BPV variable gets set with the 1.0.0+ value, so it
> can be used in the filespath, so the generic files go there, and individual
> versions can override further if necessary.
>
> I've been experimenting with a set of files and recipes to build every
> version of nano that exists, from 1.0.0 through 2.2.3, with one recipe for
> each set of versions.  I'm still investigating to find the optimal workflow
> with this, someone else may want just one recipe for all versions, or they
> may want to leave it as is, just one recipe per version, but I suspect this
> may reduce the number of files duplicated across filespaths amongst versions
> which could be grouped together into a single recipe.
>
> 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 :)
>
> The bitbake changes: http://github.com/kergoth/BitBake/commits/bbversions
> The repository with my experimentations with nano (haven't pushed since I
> split the recipe by version range yet): http://gist.github.com/338382
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>



-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: 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@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: BBVERSIONS

[Chris Larson]

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

Re: BBVERSIONS

[Martin Jansa]

On Tue, Mar 23, 2010 at 09:07:01AM -0700, Chris Larson wrote:
> 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?

Sure, I'm just pointing that expected use-cases where it's really
usefull are a bit limited by those concerns above. So it was more for
your question if it's worth it :). 


> 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.

At least I'm happy to see another dev waiting for 1.10 required by
oe.dev :).

Cheers,

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

Re: BBVERSIONS

[Khem Raj]

On (23/03/10 10:47), Martin Jansa 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 :)

I think it could be an useful experiment as an option for packages which
dont change so much as the releases progress. However adding stuff to build
for multiple version in same recipe can be error prone. I have seen this
happening with changes made to .inc files when other recipes break
silently.

Currently we have per version recipes (roughly) which gives a playground
for a given version one can do customization fairly easily and they are
contained.

If I make change to a given version the recipe will also affect other
versions even if nothing of interest was done for those versions due to say PR bump isnt it ?

I think moving bitrotted recipes to different location is probably also a good
way to speed up parsing time for general users without changing the bb
files too much. 

Recently asking new users about bitbake they were pretty much confused with
syntax I think this will add to it.

Thanks

-Khem

Re: BBVERSIONS

[Chris Larson]

On Tue, Mar 23, 2010 at 1:45 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On (23/03/10 10:47), Martin Jansa 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 :)
>
> I think it could be an useful experiment as an option for packages which
> dont change so much as the releases progress. However adding stuff to build
> for multiple version in same recipe can be error prone. I have seen this
> happening with changes made to .inc files when other recipes break
> silently.
>
> Currently we have per version recipes (roughly) which gives a playground
> for a given version one can do customization fairly easily and they are
> contained.
>
> If I make change to a given version the recipe will also affect other
> versions even if nothing of interest was done for those versions due to say
> PR bump isnt it ?
>
> I think moving bitrotted recipes to different location is probably also a
> good
> way to speed up parsing time for general users without changing the bb
> files too much.
>
> Recently asking new users about bitbake they were pretty much confused with
> syntax I think this will add to it.


Well, as I said previously in the thread, I personally think it's a better
idea to have the old recipes brought forward with current developments, even
if it breaks other versions, than let the other recipes rot and never pick
up those fixes.  This is the dev branch, shit breaks, it happens.  That
said, you can still constrain a change to a single version with this feature
used, by using the version override.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics