On Wed, Sep 26, 2012 at 11:36 AM, Wolfgang Denk <w...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
