[bitbake-devel] [PATCH] Remove whitelisted vars from non-task deps

[Chris Larson]

On Wed, Apr 4, 2012 at 10:02 AM, Matthew McClintock
<msm-fsl at mcclintock.net> wrote:
> On Tue, Apr 3, 2012 at 4:23 PM, Christopher Larson <kergoth at gmail.com> wrote:
>> From: Christopher Larson <chris_larson at mentor.com>
>>
>> Though the value of variables in the BB_BASEHASH_WHITELIST is kept out of the
>> checksums, dependency on them is not, at least for variables and non-task
>> functions. In the code, the whitelist is removed from the overall task dep
>> list, but not the individual variable deps. The result of this is that
>> functions like sysroot_stage_all and oe_runmake end up with whitelisted
>> variables like TERM listed in their dependencies, which means that doing
>> a 'unset TERM' before building will result in all checksums for tasks that
>> depend on those changing, and shared state reuse not behaving correctly.
>>
>> This is only really a potential issue for variables from the environment, as
>> it's the existance/removal of the variable that's an issue, not its value, and
>> the other whitelisted variables are set in our metadata. This which means in
>> practical terms the only cases where this is likely to be an issue are in
>> environments where one of the following are unset: TERM, LOGNAME, HOME, USER,
>> PWD, SHELL. This may seem like an unlikely circumstance, but is in fact a real
>> issue for those of us using autobuilders. Jenkins does not set TERM when
>> executing shell, which means shared state archives produced by your jenkins
>> server would not be fully reused by an actual user.
>>
>> Fixed by removing the whitelisted elements from the individual variable deps,
>> not just the accumulated result.
>
> Which recipes/packages were you seeing this on? I've noticed the TERM
> issue on several packages but not on all of them.

One I know of off the top of my head was avahi. The sstate archives
for it which came out of jenkins were not being used. As one example,
the populate-sysroot archive wasn't being used due to the TERM
dependency being added/removed to/from the dependency list for
sysroot_stage_*.
-- 
Christopher Larson