From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
<bitbake-devel@lists.openembedded.org>
Subject: Re: [PATCH 2/2] fetch2: Unify BB_FETCH_PREMIRRORONLY
Date: Fri, 22 Mar 2019 11:47:04 +0800 [thread overview]
Message-ID: <46033f6e-3fb0-36c1-7597-e2e2e3e2ebab@windriver.com> (raw)
In-Reply-To: <57405634beb17bee8c7cf82af7d8bf672a21ed52.camel@linuxfoundation.org>
Hi RP,
On 3/22/19 7:35 AM, Richard Purdie wrote:
> On Wed, 2019-03-20 at 14:40 +0800, Robert Yang wrote:
>> The fetch2/__init__.py checks whether "BB_FETCH_PREMIRRORONLY" ==
>> "1", but
>> fetch2/git.py and hg.py checks whether it is None, this makes it
>> discontinuous,
>> and BB_FETCH_PREMIRRORONLY = "0" doens't work as expected in the
>> later case,
>> so unify it to the previous one. (As BB_NO_NETWORK does).
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> ---
>> bitbake/lib/bb/fetch2/git.py | 2 +-
>> bitbake/lib/bb/fetch2/hg.py | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/bitbake/lib/bb/fetch2/git.py
>> b/bitbake/lib/bb/fetch2/git.py
>> index 1a8ebe3..e021f33 100644
>> --- a/bitbake/lib/bb/fetch2/git.py
>> +++ b/bitbake/lib/bb/fetch2/git.py
>> @@ -318,7 +318,7 @@ class Git(FetchMethod):
>> def try_premirror(self, ud, d):
>> # If we don't do this, updating an existing checkout with
>> only premirrors
>> # is not possible
>> - if d.getVar("BB_FETCH_PREMIRRORONLY") is not None:
>> + if d.getVar("BB_FETCH_PREMIRRORONLY") == "1":
>> return True
>> if os.path.exists(ud.clonedir):
>> return False
>> diff --git a/bitbake/lib/bb/fetch2/hg.py
>> b/bitbake/lib/bb/fetch2/hg.py
>> index 936d043..5a3db92 100644
>> --- a/bitbake/lib/bb/fetch2/hg.py
>> +++ b/bitbake/lib/bb/fetch2/hg.py
>> @@ -99,7 +99,7 @@ class Hg(FetchMethod):
>> def try_premirror(self, ud, d):
>> # If we don't do this, updating an existing checkout with
>> only premirrors
>> # is not possible
>> - if d.getVar("BB_FETCH_PREMIRRORONLY") is not None:
>> + if d.getVar("BB_FETCH_PREMIRRORONLY") == "1":
>> return True
>> if os.path.exists(ud.moddir):
>> return False
>
> Can we use bb.utils.to_boolean() in all cases to be consistent please?
Thanks, I will update it.
I have another question about try_premirror(), are there any side effects
if we make try_premirror() always return true? I mean that:
def try_premirror(self, ud, d):
return True
I've met a problem recently, when rework in an old build, e.g, suppose
there is a foo_git.bb:
1) Add foo.git to PREMIRROR
2) In builddir
$ bitbake foo
Then foo.git will be fetched into DL_DIR, which is premirror_foo.git.
3) Upgrade foo_git.bb's SRCREV, and this SRCREV isn't in premirror_foo.git since
it's very new.
4) Upgrade foo.git in PREMIRROR, now it contains the SRCREV of step 3
5) Go to the old builddir
$ bitbake foo
Then it won't update from PREMIRROR if BB_FETCH_PREMIRRORONLY is not set,
and it would fail to build if BB_NO_NETWORK = "1" since SRCREV can't be found
in DL_DIR. Now the problem is:
- Set BB_FETCH_PREMIRRORONLY = "0" and BB_NO_NETWORK = "1" will make foo fail
to build.
- Set BB_FETCH_PREMIRRORONLY = "1" will make it work for foo_git.bb, but it
may not work for another recipe such as foo_X_git.bb even if
BB_NO_NETWORK = "0".(Imagine the PREMIRROR doesn't contain foo_X_git.bb's
SRCREV)
- Set BB_FETCH_PREMIRRORONLY = "0" and BB_NO_NETWORK = "0" will make foo work,
but it won't upgrade from PREMIRROR, though everything is up-to-date there.
It will update DL_DIR from SRC_URI, this isn't good when network is slow.
Things will be much easier if make try_premirror() always return True.
// Robert
>
> Cheers,
>
> Richard
>
>
>
next prev parent reply other threads:[~2019-03-22 3:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 6:40 [PATCH 0/2] fetch2: Unify BB_FETCH_PREMIRRORONLY Robert Yang
2019-03-20 6:40 ` [PATCH 1/2] fetch2: runfetchcmd(): Print workdir in debug message Robert Yang
2019-03-20 6:40 ` [PATCH 2/2] fetch2: Unify BB_FETCH_PREMIRRORONLY Robert Yang
2019-03-21 23:35 ` Richard Purdie
2019-03-22 3:47 ` Robert Yang [this message]
2019-03-22 11:18 ` richard.purdie
2019-03-25 7:45 ` Robert Yang
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=46033f6e-3fb0-36c1-7597-e2e2e3e2ebab@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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