[oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as broken

[Slater, Joseph]

> -----Original Message-----
> From: Joe MacDonald [mailto:Joe_MacDonald at mentor.com]
> Sent: Thursday, July 30, 2015 8:41 AM
> To: Slater, Joseph
> Cc: openembedded-devel at lists.openembedded.org
> Subject: Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as
> broken
> 
> [Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as broken] On
> 15.07.28 (Tue 19:39) Slater, Joseph wrote:
> 
> >
> > > -----Original Message-----
> > > From: openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-devel-
> > > bounces at lists.openembedded.org] On Behalf Of Joe MacDonald
> > > Sent: Wednesday, July 22, 2015 1:31 PM
> > > To: openembedded-devel at lists.openembedded.org
> > > Subject: Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as
> > > broken
> > >
> > > [[oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as broken] On
> > > 15.07.22 (Wed 11:54) Joe Slater wrote:
> > >
> > > > We will need the conditional dependency on systemd.  It is
> > > > not a good idea to use PNBLACKLIST in a recipe, and the
> > >
> > > It isn't a good idea to have a recipe that needs to be blacklisted.  :-)
> > >
> > > That said, it's here and there's still an argument for supporting it, so
> > > why remove PNBLACKLIST and replace it with something less obvious?
> >
> > Blacklisting oneself is esthetically unpleasing.
> 
> I won't argue there.  But it happens because it's a less violent option
> than kicking the recipe to the curb and waiting for pick-up day.  It
> does allow someone using the recipe to come along and still use it for
> their scenario if they need it and they know the reason for the
> blacklisting doesn't apply to them.
> 
> > But, beyond that, it doesn't work for multilib variants, and for some
> > reason PNBLACKLIST[${PN}] does not parse.
> 
> I don't know about that, but maybe a patch to poky is appropriate
> instead.  It's nothing to be proud of, but there are dozens of recipes
> in meta-openembedded/ right now that are blacklisted, unless you're
> planning on submitting the same construct to replace all of them, I
> don't think there's much more to discuss on it.
> 
> I'm marking this 'changes requested'.  Do you think you could re-submit
> with just the dependency change?

Sure.  I'll check, though, if maybe PNBLACKLIST["${PN}"] parses, in which
case I'll use that for the blacklisting.

Joe

> 
> Thanks,
> -J.
> 
> >
> > Joe
> >
> >
> > >
> > > No objection to a conditional dependency on systemd.
> > >
> > > -J.
> > >
> > > > version here does not suppress lib32-ypbind-mt.
> > > >
> > > > Signed-off-by: Joe Slater <jslater at windriver.com>
> > > > ---
> > > >  recipes-support/nis/ypbind-mt_2.2.bb |    6 ++++--
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb b/meta-
> > > networking/recipes-support/nis/ypbind-mt_2.2.bb
> > > > index 4f8bf48..359b020 100644
> > > > --- a/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb
> > > > +++ b/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb
> > > > @@ -15,10 +15,12 @@ of known secure NIS server (/etc/yp.conf) Binds to \
> > > >  the server which answered as first. \
> > > >  "
> > > >  HOMEPAGE = "http://www.linux-nis.org/nis/ypbind-mt/index.html"
> > > > -DEPENDS = "yp-tools"
> > > > +DEPENDS = "yp-tools ${@base_contains('DISTRO_FEATURES', 'systemd', 'systemd', '',
> d)}"
> > > >  PROVIDES += "ypbind"
> > > >
> > > > -PNBLACKLIST[ypbind-mt] ?= "BROKEN: Depends on broken yp-tools"
> > > > +python () {
> > > > +    raise bb.parse.SkipPackage("BROKEN: Depends on broken yp-tools")
> > > > +}
> > > >
> > > >  SRC_URI = "http://www.linux-nis.org/download/ypbind-mt/${BP}.tar.bz2 \
> > > >             file://ypbind-yocto.init \
> > > > --
> > > > 1.7.9.5
> > > >
> > > --
> > > -Joe MacDonald.
> > > :wq
> --
> -Joe MacDonald.
> :wq