Re: [PATCH] bitbake.conf: Changed PSEUDO_LOCALSTATEDIR assignment to unconditional.

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-08-10 at 02:06 +0000, James Limbouris wrote:
> 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.

Something here isn't adding up correctly to me.

bitbake should not be seeing any PSEUDO_LOCALSTATEDIR from the pseudo
binary since its not a whitelisted environment variable. The ?= should
therefore always being assigned as there wouldn't be a previous version
of the variable.

I'd like to understand what value the variable is taking (which would
stop the ?= applying).

Are you using BB_PRESERVE_ENV ?

Cheers,

Richard

> 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