Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: ChenQi <Qi.Chen@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] buildhistory.bbclass: always record PKG, PKGE, PKGV and PKGR
Date: Thu, 17 Oct 2013 14:07:10 +0100	[thread overview]
Message-ID: <11814780.RMgQkNuoA0@helios> (raw)
In-Reply-To: <525F5002.6050404@windriver.com>

On Thursday 17 October 2013 10:48:34 ChenQi wrote:
> On 10/16/2013 03:58 AM, Randy MacLeod wrote:
> > On 13-10-01 01:28 PM, Mark Hatle wrote:
> >> On 9/30/13 11:26 AM, Paul Eggleton wrote:
> >>> On Thursday 26 September 2013 13:23:32 Qi.Chen@windriver.com wrote:
> >>>> From: Chen Qi <Qi.Chen@windriver.com>
> >>>> 
> >>>> The buildhistory.bbclass always records PV instead of PKGV. However,
> >>>> the buildhistory-diff script treats PKGV as a monitored variable
> >>>> instead of PV.
> >>>> 
> >>>> If a recipe's PV changes, for example, hello_1.0.bb is renamed to
> >>>> hello_2.0.bb, then buildhistory-diff reports nothing because PV is
> >>>> not monitored and PKGV is not recorded.
> >>>> 
> >>>> So the buildhistory.bbclass should always record PKGV no matter it
> >>>> equals to PV or not.
> >>>> 
> >>>> The same logic applies to PKG, PKGE and PKGR.
> >>>> 
> >>>> [YOCTO #5263]
> >>>> 
> >>>> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> >>>> ---
> >>>> 
> >>>>   meta/classes/buildhistory.bbclass |    8 ++++----
> >>>>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>>> 
> >>>> diff --git a/meta/classes/buildhistory.bbclass
> >>>> b/meta/classes/buildhistory.bbclass index 3da03c8..cea917c 100644
> >>>> --- a/meta/classes/buildhistory.bbclass
> >>>> +++ b/meta/classes/buildhistory.bbclass
> >>>> 
> >>>> @@ -277,10 +277,10 @@ def write_pkghistory(pkginfo, d):
> >>>>           f.write("PR = %s\n" %  pkginfo.pr)
> >>>>           
> >>>>           pkgvars = {}
> >>>> 
> >>>> -        pkgvars['PKG'] = pkginfo.pkg if pkginfo.pkg != pkginfo.name
> >>>> else ''
> >>>> -        pkgvars['PKGE'] = pkginfo.pkge if pkginfo.pkge != pkginfo.pe
> >>>> else
> >>>> '' -        pkgvars['PKGV'] = pkginfo.pkgv if pkginfo.pkgv !=
> >>>> pkginfo.pv
> >>>> else '' -        pkgvars['PKGR'] = pkginfo.pkgr if pkginfo.pkgr !=
> >>>> pkginfo.pr else '' +        pkgvars['PKG'] = pkginfo.pkg
> >>>> +        pkgvars['PKGE'] = pkginfo.pkge
> >>>> +        pkgvars['PKGV'] = pkginfo.pkgv
> >>>> +        pkgvars['PKGR'] = pkginfo.pkgr
> >>>> 
> >>>>           for pkgvar in pkgvars:
> >>>>               val = pkgvars[pkgvar]
> >>> 
> >>>>               if val:
> >>> Please see my comment on the bug (just added):
> >>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5263
> >> 
> >> Already added to the bug, but here so people not watching the bug can
> >> see:
> >> 
> >> I believe this change is requested because otherwise there is no way to
> >> detect a package upgrade/uprev when using buildhistory.  This type of
> >> upgrade can happy when comparing no-GPLv3 and GPLv3 builds -- or just
> >> simple software updates when a layer gets updated.
> >> 
> >> We want to use the buildhistory from one build to the next to look for
> >> changes that have occurred that may be unexpected.
> >> 
> >> --Mark
> > 
> > Paul,
> > Any comments?
> > Qi replied to your comment in bugzilla.
> > 
> > Qi,
> > Perhaps you need to post an example showing how this change
> > helps for a package upgrade and compare it to what happens when
> > the patch is not applied.
> > 
> > // Randy
> 
> Hi All,
> 
> Use the following steps to test the buildhistory.
> 
> 1. bitbake chown-example
> 2. mv ../meta-local/recipes-core/chown-example/chown-example_1.0.bb
> ../meta-local/recipes-core/chown-example/chown-example_2.0.bb
> 3. bitbake chown-example
> 4. buildhistory-diff
> 
> Testing Result
> -------------------
> *) Without the patch
>     <No Output for buildhistory-diff>
> *) With the patch
> <Below is the output.>
> chenqi@pek-qchen1-u12u4:~/poky/build$ buildhistory-diff
> packages/i586-poky-linux/chown-example/chown-example-dbg: PKGV changed
> from 1.0 to 2.0
>    * PV changed from "1.0" to "2.0"
> packages/i586-poky-linux/chown-example/chown-example-dev: PKGV changed
> from 1.0 to 2.0
>    * PV changed from "1.0" to "2.0"
> packages/i586-poky-linux/chown-example/chown-example-doc: PKGV changed
> from 1.0 to 2.0
>    * PV changed from "1.0" to "2.0"
> packages/i586-poky-linux/chown-example/chown-example-locale: PKGV
> changed from 1.0 to 2.0
>    * PV changed from "1.0" to "2.0"
> packages/i586-poky-linux/chown-example/chown-example-staticdev: PKGV
> changed from 1.0 to 2.0
>    * PV changed from "1.0" to "2.0"
> packages/i586-poky-linux/chown-example/chown-example: PKGV changed from
> 1.0 to 2.0
>    * PV changed from "1.0" to "2.0"
> 
> Best Regards,
> Chen Qi

A couple of things:

1) buildhistory-diff is intentionally not reporting version values changing, on 
the assumption that most of the time the user is aware when these changes 
occur. Based on what you have described there is a case for adding an option 
to report these changes however.

2) The patch as submitted not only records redundant information but also 
breaks the ability to see when the value changes from the "default" value to a 
custom value or vice versa, which is what the code was originally designed to 
do.

I am about to send a different patch that adds the option to show these changes 
and addresses #2 above.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


      reply	other threads:[~2013-10-17 13:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26  5:23 [PATCH 0/1] buildhistory.bbclass: always record PKG, PKGE, PKGV and PKGR Qi.Chen
2013-09-26  5:23 ` [PATCH 1/1] " Qi.Chen
2013-09-30 16:26   ` Paul Eggleton
2013-10-01 17:28     ` Mark Hatle
2013-10-15 19:58       ` Randy MacLeod
2013-10-15 21:32         ` Paul Eggleton
2013-10-17  2:48         ` ChenQi
2013-10-17 13:07           ` Paul Eggleton [this message]

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=11814780.RMgQkNuoA0@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=Qi.Chen@windriver.com \
    --cc=openembedded-core@lists.openembedded.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