On Mon, 2011-08-08 at 17:11 +0800, Yu Ke wrote:
> on 2011-8-5 18:37, Lianhao Lu wrote:
> > [YOCTO #1337]
> > Using ghostscript-native instead of ${PN}-native in DEPENDS to correct
> > the invalid DEPENDS in multilib cases.
> >
> > Signed-off-by: Lianhao Lu<lianhao...@intel.com>
> > ---
> > .../ghostscript/ghostscript_9.02.bb | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
> > b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
> > index 28c6c9e..2e46734 100644
> > --- a/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
> > +++ b/meta/recipes-extended/ghostscript/ghostscript_9.02.bb
> > @@ -17,7 +17,7 @@ LIC_FILES_CHKSUM =
> > "file://LICENSE;md5=d151214b3131251dfc9d858593acbd24"
> >
> > PR = "r4"
> >
> > -DEPENDS = "${PN}-native tiff jpeg fontconfig cups"
> > +DEPENDS = "ghostscript-native tiff jpeg fontconfig cups"
> > DEPENDS_virtclass-native = ""
> >
> > SRC_URI_BASE =
> > "http://downloads.ghostscript.com/public/ghostscript-${PV}.tar.bz2";
>
> This looks a generic issue to me. i.e. when the dependency ends with
> "-native", we should make sure it won't has multilib prefix. so the
> following patch will be more generic. or at least, we should document
> somewhere that "${PN}-native" dependency is not right.
>
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index 6e1669f..c73e5f9 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -43,7 +43,11 @@ python __anonymous () {
> newdeps = []
> for dep in deps:
> if dep.endswith(("-native", "-native-runtime")):
> - newdeps.append(dep)
> + if dep.startswith(variant):
> + # remove the leading MLPREFIX
> + newdeps.append(dep[len(variant)+1:])
> + else:
> + newdeps.append(dep)
> else:
> newdeps.append(extend_name(dep))
> d.setVar(varname, " ".join(newdeps))
>
> comment? if it is Ok, I will submit a patch.
I'm not sure I like this. I think fixing the individual recipes to use
BPN instead of PN might be a better way to handle this.
We could also error upon detecting this situation instead of magically
fixing it up as above...
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
