Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] classes: Update to use corrected bb.utils.explode_dep_versions2 API
Date: Tue, 02 Oct 2012 21:17:57 +0100	[thread overview]
Message-ID: <1349209077.18301.11.camel@ted> (raw)
In-Reply-To: <506B224B.3090509@windriver.com>

On Tue, 2012-10-02 at 12:20 -0500, Mark Hatle wrote:
> On 10/1/12 7:10 PM, Richard Purdie wrote:
> > The bb.utils.explode_dep_versions function has issues where dependency information
> > can be lost. The API doesn't support maintaining the correct information so this
> > changes to use a new function which correctly handles the data.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> > diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
> > index dc32c81..0f49936 100644
> > --- a/meta/classes/libc-common.bbclass
> > +++ b/meta/classes/libc-common.bbclass
> > @@ -29,14 +29,7 @@ python populate_packages_prepend () {
> >           d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
> >           d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
> >           # For backward compatibility with old -dbg package
> > -
> > -        def add_dep(var, dep):
> > -            deps = bb.utils.explode_dep_versions(d.getVar(var + '_' + bpn, True) or "")
> > -            if not dep in deps:
> > -                deps[dep] = ""
> > -                d.setVar(var + '_' + bpn, bb.utils.join_deps(deps, commasep=False))
> > -
> > -        add_dep('RPROVIDES', 'libc-dbg')
> > -        add_dep('RCONFLICTS', 'libc-dbg')
> > -        add_dep('RREPLACES', 'libc-dbg')
> > +        d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
> > +        d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
> > +        d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
> >   }
> 
> The above is almost the same as the original code.  The problem with appendVar 
> is that then you get duplicate entries.  With the new code, I know we won't get 
> exceptions, but do we really want the duplicates?
> 
> Everything else looks good.

Its not really an error to have duplicates in the field. I'm fine with
avoiding it where it makes sense but I don't like adding too much
runtime cost or complexity.

In the above case it will get filtered out later anyway so I'm not
really bothered by it and prefer the simpler syntax.

Cheers,

Richard




      reply	other threads:[~2012-10-02 20:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02  0:10 [PATCH] classes: Update to use corrected bb.utils.explode_dep_versions2 API Richard Purdie
2012-10-02 17:20 ` Mark Hatle
2012-10-02 20:17   ` Richard Purdie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1349209077.18301.11.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox