Patchwork [2/5] conf/bitbake.conf: Added variables for PR service.

login
register
mail settings
Submitter Lianhao Lu
Date May 26, 2011, 11:55 a.m.
Message ID <a24e8ddae8f503f60c9151aab0f35627393ed285.1306401007.git.lianhao.lu@intel.com>
Download mbox | patch
Permalink /patch/4823/
State New, archived
Headers show

Comments

Lianhao Lu - May 26, 2011, 11:55 a.m.
1. change BB_SIGNATURE_HANDLER from basic to basichash.

2. Added following variables for PR service:
USE_PR_SERV: flag of whether to use the network PR service
PRAUTOINX: search index for the network PR service
PKGV/PKGR: version and revision used in package feed

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
---
 meta/conf/bitbake.conf |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)
Phil Blundell - May 26, 2011, 11:59 a.m.
On Thu, 2011-05-26 at 19:55 +0800, Lianhao Lu wrote:
> -EXTENDPV = "${EXTENDPEVER}${PV}-${PR}"
> +EXTENDPV = "${EXTENDPEVER}${PV}-${PKGR}"

That looks a bit weird.  Is it really correct to be mixing PV and PKGR
like that?

FWIW, oe master has:

EXTENDPE = "${@int('${PE}') and '${PE}_' or ''}"
EXTENDPEVER = "${@int('${PE}') and '${PE}:' or ''}"
EXTENDPV = "${EXTENDPEVER}${PV}-${PR}${DISTRO_PR}"

PKGV	?= "${PV}"
PKGR	?= "${PR}${DISTRO_PR}"

EXTENDPKGEVER = "${@['','${PKGE\x7d:'][bb.data.getVar('PKGE',d,1) > 0]}"
EXTENDPKGV ?= "${EXTENDPKGEVER}${PKGV}-${PKGR}"

and, although there are a couple of uses of ${EXTENDPV} that should
perhaps be ${EXTENDPKGV}, this arrangement seems sensible otherwise.

p.
Lianhao Lu - May 26, 2011, 12:43 p.m.
Phil Blundell wrote on 2011-05-26:
> On Thu, 2011-05-26 at 19:55 +0800, Lianhao Lu wrote:
>> -EXTENDPV = "${EXTENDPEVER}${PV}-${PR}"
>> +EXTENDPV = "${EXTENDPEVER}${PV}-${PKGR}"
> 
> That looks a bit weird.  Is it really correct to be mixing PV and PKGR like that?
> 
> FWIW, oe master has:
> 
> EXTENDPE = "${@int('${PE}') and '${PE}_' or ''}"
> EXTENDPEVER = "${@int('${PE}') and '${PE}:' or ''}"
> EXTENDPV = "${EXTENDPEVER}${PV}-${PR}${DISTRO_PR}"
> 
> PKGV	?= "${PV}"
> PKGR	?= "${PR}${DISTRO_PR}"
> 
> EXTENDPKGEVER = "${@['','${PKGE\x7d:'][bb.data.getVar('PKGE',d,1) > 0]}"
> EXTENDPKGV ?= "${EXTENDPKGEVER}${PKGV}-${PKGR}"
> 
> and, although there are a couple of uses of ${EXTENDPV} that should
> perhaps be ${EXTENDPKGV}, this arrangement seems sensible otherwise.
> 

The problem is that in OE-core the default -deb/-dbg packages are all using EXTENDPV, as well as some other recipes. Do you mean we should make them all using EXTENDPKGV instead of EXTENDPV? If this is the way, I think PKGE should be used instead of PE in package_xxx.bbclass, though currently I don't see any recipe in OE using PKGE, but some of them do use PE.

Best Regards,
Lianhao
Phil Blundell - May 26, 2011, 12:47 p.m.
On Thu, 2011-05-26 at 20:43 +0800, Lu, Lianhao wrote:
> The problem is that in OE-core the default -deb/-dbg packages are all
> using EXTENDPV, as well as some other recipes. Do you mean we should
> make them all using EXTENDPKGV instead of EXTENDPV?

As far as I can tell, yes, that would be the right thing to do.  That's
what I was thinking of when I mentioned the "couple of uses" before.
The only reason I hesitate is that, although the current behaviour looks
like it should be wrong, nobody has actually complained about it and
that makes me wonder if I have misunderstood something.

I guess someone needs to do a few tests to figure out what exactly is
going on there.  But I am fairly sure that creating a hybrid PV+PKGR is
not a good thing to do; it should be either one thing or the other, and
as far as I know everything on the output side should be using PKGxx.

p.
Lianhao Lu - May 26, 2011, 1:02 p.m.
Phil Blundell wrote on 2011-05-26:
> On Thu, 2011-05-26 at 20:43 +0800, Lu, Lianhao wrote:
>> The problem is that in OE-core the default -deb/-dbg packages are
>> all using EXTENDPV, as well as some other recipes. Do you mean we
>> should make them all using EXTENDPKGV instead of EXTENDPV?
> 
> As far as I can tell, yes, that would be the right thing to do.
> That's what I was thinking of when I mentioned the "couple of uses" before.
> The only reason I hesitate is that, although the current behaviour
> looks like it should be wrong, nobody has actually complained about it
> and that makes me wonder if I have misunderstood something.
> 
> I guess someone needs to do a few tests to figure out what exactly is
> going on there.  But I am fairly sure that creating a hybrid PV+PKGR
> is not a good thing to do; it should be either one thing or the other,
> and as far as I know everything on the output side should be using PKGxx.
> 

Maybe all the recipes are using the PKGV default value (?= ${PV}, so this just happens to make EXTENDPKGV equal to EXTENDPV. In what situation we should use EXTENDPV but not EXTENDPKGV then?

Best Regards,
Lianhao
Phil Blundell - May 26, 2011, 1:07 p.m.
On Thu, 2011-05-26 at 21:02 +0800, Lu, Lianhao wrote:
> Maybe all the recipes are using the PKGV default value (?= ${PV}, so
> this just happens to make EXTENDPKGV equal to EXTENDPV. 

Yes, could be.  The most common situation where PKGV != PV is when
something like gitpkgv.bbclass is in use, which doesn't happen all that
often.  The main effect of using the wrong vars would be to make the
-doc/-dbg/-dev packages of gitpkgv-using recipes uninstallable, and I
guess I could believe that this might be happening without anybody
having noticed.

> In what situation we should use EXTENDPV but not EXTENDPKGV then?

Good question.  I suspect the answer is probably "none".

p.
Richard Purdie - May 26, 2011, 2:08 p.m.
On Thu, 2011-05-26 at 14:07 +0100, Phil Blundell wrote:
> On Thu, 2011-05-26 at 21:02 +0800, Lu, Lianhao wrote:
> > Maybe all the recipes are using the PKGV default value (?= ${PV}, so
> > this just happens to make EXTENDPKGV equal to EXTENDPV. 
> 
> Yes, could be.  The most common situation where PKGV != PV is when
> something like gitpkgv.bbclass is in use, which doesn't happen all that
> often.  The main effect of using the wrong vars would be to make the
> -doc/-dbg/-dev packages of gitpkgv-using recipes uninstallable, and I
> guess I could believe that this might be happening without anybody
> having noticed.
> 
> > In what situation we should use EXTENDPV but not EXTENDPKGV then?
> 
> Good question.  I suspect the answer is probably "none".

For what its worth I agree with your conclusions, it probably is broken
and nobody has noticed.

Lets keep this simpler and just have one variable :)

Cheers,

Richard

Patch

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 35fd6f8..06f5fd6 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -153,9 +153,17 @@  PR = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[2] or 'r0
 PF = "${PN}-${EXTENDPE}${PV}-${PR}"
 EXTENDPE = "${@['','${PE\x7d_'][bb.data.getVar('PE',d,1) > 0]}"
 EXTENDPEVER = "${@['','${PE\x7d:'][bb.data.getVar('PE',d,1) > 0]}"
-EXTENDPV = "${EXTENDPEVER}${PV}-${PR}"
+EXTENDPV = "${EXTENDPEVER}${PV}-${PKGR}"
 P = "${PN}-${PV}"
 
+EXTENDPRAUTO = "${@['.${PRAUTO\x7d',''][bb.data.getVar('PRAUTO',d,1) is None]}"
+PRAUTOINX = "${PF}${DISTRO_PR}"
+
+PKGV ?= "${PV}"
+PKGR ?= "${PR}${DISTRO_PR}${EXTENDPRAUTO}"
+EXTENDPKGVER = "${@['','${PKGE\x7d:'][bb.data.getVar('PKGE',d,1) > 0]}"
+EXTENDPKGV ?= "${EXTENDPKGVER}${PKGV}-${PKGR}"
+
 # Base package name
 # Automatically derives "foo" from "foo-native", "foo-cross" or "foo-initial"
 # otherwise it is the same as PN and P
@@ -163,6 +171,11 @@  SPECIAL_PKGSUFFIX = "-native -cross -initial -intermediate -nativesdk -crosssdk
 BPN = "${@base_prune_suffix(bb.data.getVar('PN', d, True), bb.data.getVar('SPECIAL_PKGSUFFIX', d, True).split(), d)}"
 BP = "${BPN}-${PV}"
 
+#
+# network based PR service
+#
+USE_PR_SERV = "${@[1,0][(bb.data.getVar('PRSERV_HOST',d,1) is None) or (bb.data.getVar('PRSERV_PORT',d,1) is None)]}"
+
 # Package info.
 
 SECTION = "base"
@@ -649,6 +662,7 @@  PCMCIA_MANAGER ?= "pcmcia-cs"
 DEFAULT_TASK_PROVIDER ?= "task-base"
 MACHINE_TASK_PROVIDER ?= "${DEFAULT_TASK_PROVIDER}"
 IMAGE_ROOTFS_SIZE ?= "65536"
+DISTRO_PR ?= ''
 
 # Forcefully set CACHE now so future changes to things like 
 # MACHINE don't change the path to the cache
@@ -707,7 +721,7 @@  DISTRO[unexport] = "1"
 TRANSLATED_TARGET_ARCH ??= ${TARGET_ARCH}
 
 # Setup our default hash policy
-BB_SIGNATURE_HANDLER ?= "basic"
+BB_SIGNATURE_HANDLER ?= "basichash"
 BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
 BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE"