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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
