[OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST support

[Slater, Joseph]

> -----Original Message-----
> From: Paul Eggleton [mailto:paul.eggleton at linux.intel.com]
> Sent: Wednesday, June 22, 2016 7:30 PM
> To: openembedded-core at lists.openembedded.org
> Cc: Hatle, Mark; Slater, Joseph; Khem Raj
> Subject: Re: [OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST support
> 
> On Wed, 22 Jun 2016 17:45:55 Mark Hatle wrote:
> > On 6/22/16 5:35 PM, Khem Raj wrote:
> > > On Jun 22, 2016 2:59 PM, "Joe Slater" <jslater at windriver.com
> > >
> > > <mailto:jslater at windriver.com>> wrote:
> > >> We have encountered some issues with the use of PNBLACKLIST in recipes.
> > >> In particular, PNBLACKLIST[pkg] will not suppress building of lib32-pkg
> > >> or lib64-pkg so world builds can fail unexpectedly.
> > >>
> > >> One solution could be to implement BPNBLACKLIST[] which checks BPN
> > >> instead
> > >> of PN when a recipe is being parsed.  I have included a patch to do this.
> > >>
> > >> If this were adopted, there are many recipes under meta-openembedded that
> > >> should probably changed to use BPNBLACKLIST instead of PNBLACKLIST.
> > >
> > > Bpn will also mean native and nativesdk among others. I think its better
> > > to list multilibs explicitly.
> >
> > This is intentional.
> >
> > The problem with saying we have to list multilibs explicitly.  multilib
> > naming is arbitrary.  I can say that it probably fits the pattern of lib64,
> > lib32, libn32 and libx32.... but it doesn't have to.
> >
> > But then I'd also need to blacklist native and nativesdk versions as well..
> > so for a simple recipe that for some reason I want blacklisted, it's easier
> > to hack the recipe to just blacklist itself -- then enter 7 or more
> > blacklists.
> >
> > Using the BPNBLACKLIST I can blacklist a single recipe with one command and
> > not worry about multilibs, class extensions, etc.
> >
> > (The patch leave PNBLACKLIST, specifically so that in the case where you
> > want only partial usage blacklisted you can.)
> 
> So blacklist.bbclass already has code to extend PNBLACKLIST with multilib
> variants - so we don't actually need this for multilib, right? It only helps
> cover multilib and native/nativesdk AFAICT.

But the original problem was that PNBLACKLIST[] does not create more varflags
for multilib when used in a recipe.  Anyway, I like your approach.  Of course, I also liked
introducing a variable named SELFBLACKLIST, too.  I guess, then,

PNBLACKLIST_class-target in a recipe would be the same as
PNBLACKLIST[pkg] in a conf file is today (if pkg is a "vanilla" name).

Maybe the old syntax could be deprecated and the eventhandler in the class ditched at some point?

Joe

> 
> If we are going to make changes here I do have an alternative suggestion -
> a while ago I wrote this patch but never got around to sending it because
> I wasn't quite sure if it's the right approach. It makes PNBLACKLIST work
> a bit more like other variables where you use overrides rather than
> varflags to make it specific to a recipe:
> 
>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-
> contrib/commit/?h=paule/stuff3&id=7383419cbe69c4d62b9695e6ae65adc8b54741f7
> 
> Does anyone else see value in this?
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre