Hi All,

I'm a little saddened/annoyed/frustrated that we're less that a week before
feature freeze and yet there is still no mechanism in bitbake to handle variable
deprecation/renaming. There has also been no real discussion about how this
could/should work. People have sent out odd patches changing one specific
variable but we still don't have any core well defined plan about how to do
this. I was recently asked for a "specification" on how this should work. This
just frustrates me even more since part of the work involved in this task was to
develop such a thing.

Change doesn't "just happen", it needs planning and thinking through the details
and this simply isn't happening here. A specification doesn't exist unless
someone proposes one.

I now face some choices and all of them appear bad. I can refuse the inclusive
language changes for the next LTS. This makes me and the project look bad as
we've talked about and planned them. I can try and make them happen and rush
them through. This creates a load of work I could do without and once again
leaves me supporting any fallout. It also risks alienating users and puts the
release at risk. I could just merge adhoc changes without plan. I suspect I
would get rather negative feedback about doing that. At this point I'm not sure
there is a solution where we can "win". I do not like being forced into this
position.

In the interests of trying to be productive and move forward, let me state some
assumptions:

a) We need to tell users if an old variable is used.

b) We cannot support automatic/dynamic conversion of the old usage to a new one.
This sounds like a nice idea until you find a case where both old and new syntax
is used and then how do you combine them?

c) There are two classes of old variable names, environment ones in bitbake and
standard variables.

d) It is probably helpful to show users the new variable name where we know it.

e) Due to b), we're not going to show warnings, they need to be errors.

I gave in and started to look at what we can do. I'm going to take it as a given
that we add warnonce and erroronce log levels and message handling to bitbake
and there are patches for that in the branch below.

Beyond that there are several ways we can handle things:

a) Add a RecipeParsed event handler and handle things in the metadata in OE-
Core. This keeps bitbake clean and is simple. It wouldn't support file/line
data. The overhead isn't great. It also doesn't help any non-OE usage of bitbake
and would mean knowledge of bitbake vars in the metadata.

b) Similar to a) but put the code into bitbake in the ast.py's finalize()
function. Scott had a version of this and I've tweaked it a little to put the
bitbake variable renames into bitbake and merge in OE additions to the list:

https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/bitbake-renamevars&id=9e8c7e36cb6c9e06184f94d8670619d3361a0ffc

(needs a fragment of the patch below for bitbake_renamed_vars)

c) We could hook setVar and setVarFlag. This adds file/line info to anything set
by the core configuration which may be helpful to users.


https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=1cf65b3ce501e7927c6d319b7a4b422f44542a8e

This is more complex but adds some extra info and is possibly lower overhead. It
has the downside that parsing order matters, you'd need the renamed variables to
be early in the parsing. The order issues may mean it can miss things in
layer.conf files. The line/file info would not be shown for recipe level
settings since variable tracking is turned off for the main recipe parsing due
to the overhead it adds.


In all the above cases there are still the issues that:

1) showing errors doesn't make bitbake exit or stop the build
2) It won't handle variables from the shell environment. This will likely need
special code in bitbake.
3) There are probably some variables which are removed and no longer
used/supported which we should also tell the user about (show a message instead
of a rename?)
4) The current code doesn't handle overridden variables. This is easier to add
to c) but something for b) should be possible.

I had been wondering about c) above and keeping overhead down but I think we'll
just have to go back to b) and try and work through the issues above. I worry
that stopping the builds on error in particular is going to be problematic. I
felt I should at least share some of the complexities of this with people so
that if it doesn't end up happening, the complexity of the issue is at least
more visible.

Cheers,

Richard