Re: [PATCH 5/6] ghostscript: Fixed the incorrect DEPENDS.

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.lu@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