On Fri, Dec 02, 2011 at 08:46:43AM +0000, Mats Kärrman wrote:
> > From: openembedded-core-boun...@lists.openembedded.org
> > [openembedded-core-boun...@lists.openembedded.org] on behalf of Richard
> > Purdie [richard.pur...@linuxfoundation.org]
> > Sent: Thursday, December 01, 2011 9:33 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] Coordinating inter-layer dependencies
> >
> > On Thu, 2011-12-01 at 14:07 +0100, Martin Jansa wrote:
> > > On Thu, Dec 01, 2011 at 10:59:03AM -0200, Otavio Salvador wrote:
> > > > On Thu, Dec 1, 2011 at 10:37, Richard Purdie <
> > > > richard.pur...@linuxfoundation.org> wrote:
> > > >
> > > > > On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote:
> > > > > > A while back I've proposed to make .bbappend without corresponding
> > > > > > .bb
> > > > > > only big fat warning, but not fatal to parse. Now you cannot even
> > > > > > build
> > > > > > eglibc if there is libdrm bbappend you don't care at all about..
> > > > >
> > > > > You can do this by setting:
> > > > >
> > > > > BB_DANGLINGAPPENDS_WARNONLY
> > > > >
> > > >
> > > > This is even worse; you end up with a package without the changes done
> > > > on
> > > > the bbappend and as most bbappend files do not change PR, adding it
> > > > later
> > > > won't force a package update.
> > >
> > > If we find a way to allow PRINC in multiple bbappends for same .bb then
> > > we can say that every .bbappend should use PRINC.
> > >
> > > For record I'll include my discussion about PRINC with RP and kergoth:
> > > 10:47 < JaMa> RP__: is there any way to improve PRINC concept to allow
> > > multiple increments for same recipe while parsing multiple layers?
> > > 10:48 < RP__> JaMa: PRINC_append = ".1" ?
> > > 10:49 < JaMa> RP__: ie when meta-openmoko sets PRINC = "1" and meta-shr
> > > sets PRINC = "2" then if you're unlucky meta-openmoko is parsed later and
> > > bumping PRINC in meta-shr won't help
> > > 10:49 < RP__> JaMa: I wonder if you could do PRINC := "${PRINC + 1}"
> > > 10:50 < JaMa> and do we have default PRINC = 0 somewhere?
> > > 10:50 < RP__> JaMa: you might need to add that
> > > 10:50 < JaMa> ok, I'll try this, thanks
> > > 10:51 < JaMa> currently I'm moving PRINC only to meta-shr layer.. but
> > > that breaks stuff if someone is using any BSP layer from meta-smartphone..
> > >
> > > 14:53 < JaMa> RP__: btw that PRINC trick didn't work (int type didn't
> > > like expresion :/)
> > > 15:13 < RP__> JaMa: ah, try PRINC := "${int(PRINC) + 1}"
> > > 15:21 < JaMa> RP__: still ValueError: invalid literal for int() with base
> > > 10: '${int(PRINC) + 1}'
> > > 15:21 < JaMa> with added PRINC := 0 to bitbake.conf
> > > 15:22 < RP__> PRINC := "${int(d.getVar(PRINC)) + 1}" ? :/
> > > 15:22 < JaMa> whole log http://paste.pocoo.org/show/514437/
> > > 15:22 * RP__ was trying to be too clever I suspect
> > > 15:23 < JaMa> ValueError: invalid literal for int() with base 10:
> > > '${int(d.getVar(PRINC)) + 1}'
> > > 15:41 < kergoth> PRINC is unquoted there, so it tries to get a value for
> > > a key of None
> > > 16:24 < RP__> kergoth: right, trying to do too many things at once :/
> > > 16:24 < RP__> kergoth: any thoughts on that knotty change to add the
> > > footer?
> > > 17:05 < JaMa> kergoth: something like this? ValueError: invalid literal
> > > for int() with base 10: "${int(d.getVar('PRINC')) + 1}"
> > >
> > > Maybe someone else has better idea?
> >
> > Looking at that I was missing something obvious. Try:
> >
> > PRINC := "${@int(PRINC) + 1}"
> >
> > Cheers,
> >
> > Richard
> >
>
> As I understand it, the PRINC increases the PR of the appended recipe. Then
> the resulting package will have a version that is the same as "the next"
> version of the base recipe. Since many people (me included) hardly remember
> what they did a month ago, isn't there a big risk of confusion in your
> deployed systems if packages are upgraded there?
>
> I do something like PR .= ".local0" where "local" is the name of the layer
> containing the .bbappend.
> Of course this will create extensive version strings if multiple .bbappends
> are applied but the alternative is that you have no idea what layers that
> appended and what the the base version of the recipe really was.
So if you have some layer adding
layerB: PR .= ".b0"
and other
layerA: PR .= ".a0"
and PR appends are evaluated in this order, then you will break upgrade
patch forever if you have to remove layerB for some reason and you
cannot even fix it by bumping numbers in your layerA unless you rename
all PR appends as ".c0" right? That's why I prefer to use PRINC.
Yes it increases PR of desired number, but every time.. so if upper
layer increments PR your .bbappend will again increment it so you still
get always increasing sequence.
Only problem was multiple .bbappends overwritting PRINC value in each
other, but RP's latest proposal:
PRINC := "${@int(PRINC) + 1}"
works and I'm going to push meta-smartphone migration to this PRINC
usage instead of more common 'PRINC = "1"'
for bb in `git grep "^PRINC" . | sed 's/:.*//g'`; do sed -i 's/PRINC *=
*"\(.*\)"/PRINC := "${@int(PRINC) + \1}"/g' $bb; done
And I'll send patch here to add default PRINC = "0" to bitbake.conf,
because otherwise it fails with:
ERROR: Failure expanding variable PRINC[:=], expression was
${@int(PRINC) + 1} which triggered exception NameError: name 'PRINC' is
not defined
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
