Openembedded Bitbake Development
 help / color / mirror / Atom feed
From: Jason Wessel <jason.wessel@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org, Zhenfeng.Zhao@windriver.com
Subject: Re: [PATCH 1/1] fetch2/__init__.py: add an "auto" policy for BB_SRCREV_POLICY
Date: Tue, 21 Aug 2012 08:30:12 -0500	[thread overview]
Message-ID: <50338D64.901@windriver.com> (raw)
In-Reply-To: <1345554532.3907.76.camel@ted>

On 08/21/2012 08:08 AM, Richard Purdie wrote:
> On Thu, 2012-08-09 at 16:56 +0800, Robert Yang wrote:
>> The newly added "auto" policy is used for the SRCREV="${AUTOREV}" recipe,
>> the current BB_SRCREV_POLICY are: "clear" (default) and "cache":
>>
>> * When "clear", the "AUTOREV" recipe will not be cached in bb_cache.dat
>>
>> * When "cache", the "AUTOREV" would be cached in bb_cache.dat, but it
>>   doesn't try to get the latest revision.
>>
>> The "auto" policy is much like the "cache" except that it will try to
>> get the latest revision.
>>
>> [YOCTO #2920]
>>
>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> ---
>>  bitbake/lib/bb/fetch2/__init__.py |   12 +++++++++---
>>  1 files changed, 9 insertions(+), 3 deletions(-)
> I've been asked why I've not taken this. The simple answer is that I
> can't figure out why we need to do this. The commit message above says
> what was done but not why.
>
> I also strongly dislike "auto" as a name for this mode. "clear" and
> "cache" are at least descriptions of the behaviour, "auto" is not.
>
> So can you please explain why we need this change? What use case does it
> fix or improve or how is it useful? At the very least the commit message
> needs rewriting and the option renaming.


I had asked Robert to follow up on this and intended this as a RFC, not a final implementation.  This basically looks like the original patch I sent him when I was using the code to illustrate a possible solution to the problem of missing values from the data cache.

Let us turn this into a discussion about the problem and see if we can come up with a plausible answer.

We use the contrib/dump_cache.py to generate the entire list of possible recipes -> version -> package split mapping.  As you can imagine this data is important and can be used for a number of purposes.  I noticed a few values were missing when ever I ran the dump_cache.py and narrowed it down to the fact that anything that was listed as AUTOREV did not show up in the cache.

The desired outcome is to have the key value pairs that were used in the most recent parse show up in the cache, as opposed to completely dropping the cache values from being written at all.   For the version retrieval code, if the value in the cache is autorev, it should look up the value as one would expect.  In terms of the clean vs cache vs a 3rd state, I don't really care what key words get used.   You might not even need to add a 3rd state depending on the implementation of solution.

I didn't see a reason not to write out the cache such that it could be parsed externally.   Just because you write it, doesn't mean it has to get re-used in the case of the AUTOREV.

If I have not described the problem clearly enough, please ask further questions.  Is it a bit more clear what the nature of the problem is?

Cheers,
Jason.



  reply	other threads:[~2012-08-21 15:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-09  8:56 [PATCH 0/1] fetch2/__init__.py: add an "auto" policy for BB_SRCREV_POLICY Robert Yang
2012-08-09  8:56 ` [PATCH 1/1] " Robert Yang
2012-08-21 13:08   ` Richard Purdie
2012-08-21 13:30     ` Jason Wessel [this message]
2012-08-21 13:59       ` Richard Purdie
2012-08-21 14:14         ` Jason Wessel
2012-08-21 14:58           ` Richard Purdie

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=50338D64.901@windriver.com \
    --to=jason.wessel@windriver.com \
    --cc=Zhenfeng.Zhao@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