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

[James Limbouris]

On Wednesday, 10 August 2011 9:55 AM, Mark Hatle wrote:
> 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.
> 

Hi,

The problem is that the pseudo executable sets the environment variable
before starting its argument (bitbake) up, but we do not always use pseudo
to start bitbake. So sometimes the variable is set to the sysroot, and sometimes
it is set (by the conditional assignment in bitbake.conf) to the workdir.

Usually it is set to the workdir while building the cache, but when the cache is
invalidated, the wrapper script most often uses pseudo, setting it to the sysroot.

James