[OE-core] [PATCH] bitbake.conf: Changed PSEUDO_LOCALSTATEDIR assignment to unconditional.

Mark Hatle mark.hatle at windriver.com
Wed Aug 10 01:55:05 UTC 2011


On 8/9/11 7:32 PM, Scott Garman wrote:
> On 08/08/2011 07:04 PM, James Limbouris wrote:
>> The pseudo executable sets the PSEUDO_LOCALSTATEDIR environment variable
>> to point to a sysroot location. During an initial cache build, in which
>> pseudo is not used as it is being built, the PSEUDO_LOCALSTATEDIR is set
>> to a per-package location by bitbake.conf, and baked into the cache.
>> If the cache is subsequently invalidated, bitbake may run under pseudo,
>> and rebuild it with the sysroot location baked into the cache. This
>> results in all packages using the same, persistent db, even on package
>> rebuild, which leads to permissions errors. Making the assignment
>> unconditional corrects this problem.
> 
> I can't tell if this change would impact the use of useradd.bbclass, 
> which also sets PSEUDO_LOCALSTATEDIR in certain circumstances. Mark, can 
> you comment on whether this is a valid concern?

I've been trying to figure that out as well.  From what I can tell, as long as
the value is "${WORKDIR}/pseudo", and it's evaluated at use time -- vs
immediately.. we should be good, even with the useradd.bbclass.

(If I remember correctly, the workdir for the useradd still should either be the
package itself, or the sysroot directory.  That should be changing during the
various steps, as necessary.)

Frankly I'm still a little confused as to what is happening differently from the
"=" to the "?=" case.  My understanding is that one should indicate "it's always
this value", and the other is "use this value if one has not already been set."
 Either way we should get the same result, and the same result should end up in
any caches.  If it's not the same, this might be pointing to a different bug --
or my understanding of the processing of the variables is wrong.

So for the purposes of useradd, I don't see a problem here.. I also don't see
any issues with the general case.. but I do wonder why it's needed for the cache
to work properly.

--Mark

> Scott
> 
>>
>> Signed-off-by: James Limbouris<james at digitalmatter.com.au>
>> ---
>>   meta/conf/bitbake.conf |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 6f0b42c..9a9ab53 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -557,7 +557,7 @@ SRCPV = "${@bb.fetch2.get_srcrev(d)}"
>>   SRC_URI = "file://${FILE}"
>>
>>   # Use pseudo as the fakeroot implementation
>> -PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
>> +PSEUDO_LOCALSTATEDIR = "${WORKDIR}/pseudo/"
>>   FAKEROOTENV = "PSEUDO_PREFIX=${STAGING_DIR_NATIVE}${prefix_native} PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${STAGING_DIR_TARGET} PSEUDO_NOSYMLINKEXP=1 PSEUDO_DISABLED=0"
>>   FAKEROOTDIRS = "${PSEUDO_LOCALSTATEDIR}"
>>   PREFERRED_PROVIDER_virtual/fakeroot-native ?= "pseudo-native"
> 
> 





More information about the Openembedded-core mailing list