[OE-core] [PATCH] opkg-utils: allow disabling update-alternatives

Paul Eggleton paul.eggleton at linux.intel.com
Wed Aug 6 13:53:55 UTC 2014


On Wednesday 06 August 2014 18:58:11 sujith h wrote:
> On Wed, Aug 6, 2014 at 6:08 PM, Paul Eggleton <paul.eggleton at linux.intel.com
> > wrote:
> > 
> > On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
> > > From: Sujith H <Sujith_Haridasan at mentor.com>
> > > 
> > > This is needed to deal with the situation where we're using ipk
> > 
> > packaging,
> > 
> > > so opkg-utils must be built regardless of what update-alternatives
> > 
> > provider
> > 
> > > we prefer. The downside to the current implementation is the need to
> > 
> > adjust
> > 
> > > PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is more explicit
> > > that
> > > way.
> > > 
> > > Signed-off-by: Christopher Larson <kergoth at gmail.com>
> > > Signed-off-by: Sujith H <Sujith_Haridasan at mentor.com>
> > > ---
> > > 
> > >  meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > > b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb index
> > 
> > 693c216..952fce4
> > 
> > > 100644
> > > --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > > +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> > > @@ -19,11 +19,17 @@ TARGET_CC_ARCH += "${LDFLAGS}"
> > > 
> > >  PYTHONRDEPS = "python python-shell python-io python-math python-crypt
> > > 
> > > python-logging python-fcntl python-subprocess python-pickle
> > > python-compression python-textutils python-stringold"
> > > PYTHONRDEPS_class-native = ""
> > > 
> > > -PACKAGECONFIG = "python"
> > > +PACKAGECONFIG = "python update-alternatives"
> > > 
> > >  PACKAGECONFIG[python] = ",,,${PYTHONRDEPS}"
> > > 
> > > +PACKAGECONFIG[update-alternatives] = ",,,"
> > > +
> > > +PROVIDES_remove = "${@'virtual/update-alternatives' if
> > > 'update-alternatives' not in PACKAGECONFIG.split() else ''}"
> > 
> > If we have to do this, rather than using _remove here could we simply make
> > adding it conditional?
> 
> Isn't _remove itself conditional? Pardon me if my understanding is wrong.

What I mean is, this value gets added to PROVIDES here in the same recipe. 
Rather than unconditionally adding it then conditionally removing it, why not 
just conditionally add it?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list