[yocto] 1.3_M5.rc2 status.

[Chris Larson]

On Wed, Sep 26, 2012 at 11:36 AM, Wolfgang Denk <wd at denx.de> wrote:
>> By "better way to deal with these", what would you suggest? I don't see any
>> alternative that avoids the BSP components just disappearing for users who
>> have existing configurations.
>
> Well, the comment in  "meta-yocto/conf/bblayers.conf.sample"  says:
>
>         # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
>         # changes incompatibly
>
> This suggests that such changes are not exactly unusual.  But any such
> change will cause the build to fail, because the sanity checker uses a
> different value.

This is wrong. A compatibility break in bblayers.conf is *extremely* rare.

> If such a change is allowed and is done intentionally, then it should
> be considered "sane", and the sanity checker should not complain.

Wrong. The user has to know that they may need to change their
bblayers.conf to match the upstream structure. If it didn't complain,
they could silently break or encounter unexpected behavior.

> The problem (and the longer I think about it the less I hesitate to
> call it a plain bug) is that we allow for meta layer specific values
> of LAYER_CONF_VERSION, while still assuming a single hard-coded
> value in  meta/conf/sanity.conf  could be used as reference.
>
> This _cannot_ work.
>
> But when I'm supposed to overwrite the setting (to match the sanity
> checker's expectations) in my local conf/bblayers.conf, then why do we
> bother to set a dieferent value in the meta layer in the first place?
> And hey, why do we check this value at all if all we can do is always
> make it match manually?

Not everyone using oe-core (meta) also uses meta-yocto. Only those
using the latter were affected by this particular upstream structure
change.

> I understand the intention, but the current implementation is just
> broken, and I don't see a way to fix it.  It would probably be better
> to remove this test than to leave it as is.

Again, that'd leave the user with a bblayers.conf that may no longer
do what they intended it to do. Better to fail than potentially build
in ways not matching the user's previous expectations.
-- 
Christopher Larson