From: Mark Hatle <mark.hatle@windriver.com>
To: Scott Garman <scott.a.garman@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] bitbake.conf: Changed PSEUDO_LOCALSTATEDIR assignment to unconditional.
Date: Tue, 9 Aug 2011 20:55:05 -0500 [thread overview]
Message-ID: <4E41E4F9.60404@windriver.com> (raw)
In-Reply-To: <4E41D1B3.4090703@intel.com>
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@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"
>
>
next prev parent reply other threads:[~2011-08-10 1:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-09 2:04 [PATCH] bitbake.conf: Changed PSEUDO_LOCALSTATEDIR assignment to unconditional James Limbouris
2011-08-10 0:32 ` Scott Garman
2011-08-10 1:55 ` Mark Hatle [this message]
2011-08-10 2:06 ` James Limbouris
2011-08-10 12:06 ` Richard Purdie
2011-08-11 4:32 ` James Limbouris
2011-08-11 4:37 ` James Limbouris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E41E4F9.60404@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=scott.a.garman@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox