Re: [oe] DEPENDS += "module-build-perl-native" versus "libmodule-build-perl-native"?

2017-02-17 Thread Tim Orling

> On Feb 17, 2017, at 2:39 AM, Robert P. J. Day  wrote:

> and, predictably, the meta-cpan layer provides that very recipe:
> 
>  module-build-perl_0.4216.bb
> 

The meta-perl layer follows Debian naming of perl modules:
https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html
 


> 
>  thoughts? should some names be cleaned up to prevent this?
> 

There are many other places in the wild where the metadata is not consistent. 
The meta-openembedded/meta-perl layer-- being moderated on a mailing list — has 
some consistency. The meta-cpan layer — being authored by a NetBSD contributor 
and perl module author, on his own — does not follow the same guidelines. This 
by no means diminishes the value of the work Jens has done. But it is still 
Jen’s layer, not an officially supported OpenEmbedded layer.

IMHO, the best solution is to add perl module support to the recipetool so that 
we have an easier way to generate consistent metadata. And then try to convince 
everyone else to use the tool and follow the guidelines. We should also take a 
look at the existing metadata and clean it up.

Another option would be to have the OE community get involved in support of the 
meta-cpan layer and change the module generation code there appropriately to be 
in sync with the Debian naming guidelines.

The challenge for me personally is the same one I always have: TIME.

—Tim


> rday
> 
> -- 
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> 
> -- 
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] DEPENDS += "module-build-perl-native" versus "libmodule-build-perl-native"?

2017-02-17 Thread Robert P. J. Day

  i'm sure i asked about this before, but i currently have a hacky
workaround in a build because of the mixture of DEPENDS mentioned in
the subject line.

  first, i've pulled down the meta-cpan layer, where you can see the
consistency of recipes that depend on a native build of the perl build
module:

$ grep -rh "DEPENDS.*module-build-perl-native" *
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
DEPENDS += "module-build-perl-native"
$

and, predictably, the meta-cpan layer provides that very recipe:

  module-build-perl_0.4216.bb

OTOH, the meta-openembedded/meta-perl layer takes a slightly
different approach:

$ grep -r "DEPENDS.*module-build-perl-native" *
recipes-perl/libhtml/libhtml-tree-perl_5.03.bb:DEPENDS += 
"libmodule-build-perl-native \
$

and provides the equivalent(?) recipe:

  libmodule-build-perl_0.31.bb

the last time i checked, trying to mix those two layers verbatim
generated a build error, since i include recipes which combine the two
dependencies, and try to install the identical content at the same
location. clearly(?), i should restrict the build-time dependencies to one or
the other of those recipes for the native perl build module.

  is this even considered an issue that should be resolved? it seems
that if layers are catalogued at the https://layers.openembedded.org/,
they should be compatible and play nicely together. in this case, it's
just a naming convention incompatibility -- as i recall, the OE naming
convention for perl modules is "lib-perl", while the meta-cpan
does something different; hence, the problem.

  thoughts? should some names be cleaned up to prevent this?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel