[PATCH] layer.conf: Bumping LAYERVERSION_core

[PATCH] layer.conf: Bumping LAYERVERSION_core

[Elizabeth Flanagan]

Bumping LAYERVERSION_core to denote where meta-toolchain* is being
depreciated.

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
---
 meta/conf/layer.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index a112e86..a834765 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -9,7 +9,7 @@ BBFILE_PRIORITY_core = "5"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers
-LAYERVERSION_core = "1"
+LAYERVERSION_core = "2"
 
 # Set a variable to get to the top of the metadata location
 COREBASE = '${@os.path.normpath("${LAYERDIR}/../")}'
-- 
1.7.5.4

Re: [PATCH] layer.conf: Bumping LAYERVERSION_core

[Phil Blundell]

On Tue, 2013-07-02 at 10:45 -0700, Elizabeth Flanagan wrote:
> Bumping LAYERVERSION_core to denote where meta-toolchain* is being
> depreciated.

This commit message doesn't provide much explanation of what exactly is
going on and why this constitutes "significant changes that will
cause compatibility issues with other layers".  Can you clarify?

thanks

p.

Re: [PATCH] layer.conf: Bumping LAYERVERSION_core

[Flanagan, Elizabeth]

This goes back to my RFC:

http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39016

As we are removing meta-toolchain* and replacing it with bitbake
<imagename> -c populate_sdk this causes issues with those of us who
need to do automated builds both on the current development branch and
on prior development branches.

Example: For prior releases, I need to build meta-toolchain*. Without
having a simple way to figure out where this is no longer the case, I
(and other folks who run automated builds) end up having to jump
through a lot of hoops trying to figure out where this layer changed.
Utilizing LAYERVERSION_* to do it makes sense as there is a
significant change that would cause issues for build engineers. Prior
to this I was utilizing LCONF, which was the wrong solution, but just
happened to work in the example I'm thinking of.

-b

On Tue, Jul 2, 2013 at 11:54 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-07-02 at 10:45 -0700, Elizabeth Flanagan wrote:
>> Bumping LAYERVERSION_core to denote where meta-toolchain* is being
>> depreciated.
>
> This commit message doesn't provide much explanation of what exactly is
> going on and why this constitutes "significant changes that will
> cause compatibility issues with other layers".  Can you clarify?
>
> thanks
>
> p.
>
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release

Re: [PATCH] layer.conf: Bumping LAYERVERSION_core

[Paul Eggleton]

Hi Beth,

On Tuesday 02 July 2013 12:20:00 Flanagan, Elizabeth wrote:
> This goes back to my RFC:
> 
> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39016

Sorry, I meant to reply to that email and didn't get around to it, my 
apologies.

> As we are removing meta-toolchain* and replacing it with bitbake
> <imagename> -c populate_sdk this causes issues with those of us who
> need to do automated builds both on the current development branch and
> on prior development branches.
> 
> Example: For prior releases, I need to build meta-toolchain*. Without
> having a simple way to figure out where this is no longer the case, I
> (and other folks who run automated builds) end up having to jump
> through a lot of hoops trying to figure out where this layer changed.
> Utilizing LAYERVERSION_* to do it makes sense as there is a
> significant change that would cause issues for build engineers. Prior
> to this I was utilizing LCONF, which was the wrong solution, but just
> happened to work in the example I'm thinking of.

I can definitely see this being useful as something you can do a conditional on 
within the autobuilder code; however the original intention was that 
LAYERVERSION would only get bumped on changes that would break other layers 
(being that it was designed to match up with versioned layer dependencies) and 
I'm not sure this is one of those changes.

This situation has come up a lot over the life of this project, and I wonder 
if it's time to look at having something a bit more organised - perhaps part 
of the static configuration of the autobuilder could be within the metadata, 
i.e. just the values needed to specify the right version-specific behaviour? 
For the purposes of the Yocto Project autobuilder we can add the needed 
definitions in the meta-yocto layer rather than needing to modify OE-Core. 
Could that work?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] layer.conf: Bumping LAYERVERSION_core

[Flanagan, Elizabeth]

On Tue, Jul 2, 2013 at 2:50 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Beth,
>
> On Tuesday 02 July 2013 12:20:00 Flanagan, Elizabeth wrote:
>> This goes back to my RFC:
>>
>> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39016
>
> Sorry, I meant to reply to that email and didn't get around to it, my
> apologies.
>
>> As we are removing meta-toolchain* and replacing it with bitbake
>> <imagename> -c populate_sdk this causes issues with those of us who
>> need to do automated builds both on the current development branch and
>> on prior development branches.
>>
>> Example: For prior releases, I need to build meta-toolchain*. Without
>> having a simple way to figure out where this is no longer the case, I
>> (and other folks who run automated builds) end up having to jump
>> through a lot of hoops trying to figure out where this layer changed.
>> Utilizing LAYERVERSION_* to do it makes sense as there is a
>> significant change that would cause issues for build engineers. Prior
>> to this I was utilizing LCONF, which was the wrong solution, but just
>> happened to work in the example I'm thinking of.
>
> I can definitely see this being useful as something you can do a conditional on
> within the autobuilder code; however the original intention was that
> LAYERVERSION would only get bumped on changes that would break other layers
> (being that it was designed to match up with versioned layer dependencies) and
> I'm not sure this is one of those changes.
>
> This situation has come up a lot over the life of this project, and I wonder
> if it's time to look at having something a bit more organised - perhaps part
> of the static configuration of the autobuilder could be within the metadata,
> i.e. just the values needed to specify the right version-specific behaviour?
> For the purposes of the Yocto Project autobuilder we can add the needed
> definitions in the meta-yocto layer rather than needing to modify OE-Core.
> Could that work?
>

I really think that this is something that needs to be at the
individual layer level. One of the other reasons why is that, while
admittedly, the yocto-autobuilder is my main concern, I can see people
utilizing a lot of different autobuilders or even different
yocto-autobuilder configurations. We obviously can't track those, nor
should we.

When things change in oe-core (or any layer) enough that an image
definition disappears or changes the way we compose bblayers.conf or
auto.conf, there needs to be something that I can utilize as a
conditional so I can maintain backwards compatibility.

I've been lucky so far in that the times these have come up I can
usually peg off of LCONF_VERSION or a branch name as long as I never
need to build a prior version of the branch. But that is a really
lousy solution that has caused me no small amount of headache and I
can see the instance coming where this is not a viable solution. I'm
more than happy to hear an alternative solution though that helps not
just the yocto-autobuilder but also anyone else utilizing a different
CI system.

> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

-b

-- 
Elizabeth Flanagan
Yocto Project
Build and Release