<div dir="ltr">Robert,<div><br></div><div>You did not mention meta-perl: <a href="http://git.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl">http://git.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl</a><div><br></div><div>The perl modules in meta-perl follow Debian naming:<div><a href="https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html">https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html</a><br></div><div><a href="https://anonscm.debian.org/cgit/?q=perl">https://anonscm.debian.org/cgit/?q=perl</a><br></div><div><br></div><div>When Jens developed meta-cpan, he was trying to improve the packaging of perl modules, but did not necessarily follow the "established guidelines" for OE perl module naming (which was the meta-perl layer at the time). What he did provide is a method to use the CPAN metadata to create OE perl modules.</div><div><br></div><div>The perl packaging in OE-Core follows yet another pattern. I assume it grew out of a need to not package all the modules in a monolithic "perl-modules" package (like Debian does) for our embedded-specific usage.</div><div><br></div><div>Not an ideal situation, but we have similar issues with python modules.</div></div><div><br></div><div>Cheers.</div><div><br></div><div>--Tim</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 8:07 AM, Christopher Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <span dir="ltr"><<a href="mailto:rpjday@crashcourse.ca" target="_blank">rpjday@crashcourse.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, 25 Oct 2016, Robert P. J. Day wrote:<br>
<br>
> On Mon, 24 Oct 2016, Christopher Larson wrote:<br>
><br>
> ><br>
> > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <<a href="mailto:rpjday@crashcourse.ca" target="_blank">rpjday@crashcourse.ca</a>> wrote:<br>
> > i've just been handed a list of about 200 perl packages by their<br>
> > centos rpm names, and i want to map most, if not all, of them to their<br>
> > equivalent OE package names.<br>
> ><br>
> > my first instinct (based on not having used a lot of perl OE<br>
> > packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,<br>
> > just to fetch and build every possible module available through the OE<br>
> > perl recipe -- that will at least give me an idea of what's available.<br>
> ><br>
> > next, i can see the pattern in some OE package names -- i've<br>
> > verified that the Time::HiRes package is available in OE as<br>
> > perl-module-time-hires, which i assume is part of the dynamic naming<br>
> > being done in <a href="http://perl_5.22.1.bb" rel="noreferrer" target="_blank">perl_5.22.1.bb</a>.<br>
> ><br>
> > am i approaching this the right way?<br>
> ><br>
> ><br>
> > Could also bitbake perl, then use oe-pkgdata-util to locate the<br>
> > actual perl modules in the packages, i.e. */Time/HiRes.pm.<br>
><br>
> i once wrote a wiki page on "bb", distinguishing between queries<br>
> you could make before you did a build, versus queries that needed a<br>
> build. it seems like oe-pkgdata-util needs a completed build for<br>
> pretty much everything, do i have that right?<br>
<br>
</span> never mind, i just read this snippet from the YP ref manual:<br>
<br>
"You can use the oe-pkgdata-util command-line utility to query<br>
PKGDATA_DIR and display various package-related information. When you<br>
use the utility, you must use it to view information on packages that<br>
have already been built."<br>
<br>
so i'm assuming that means for *all* oe-pkgdata subcommands, no<br>
exceptions.</blockquote></div><br></div></div>Right, oe-pkgdata-util is about inspecting build output via pkgdata, whereas most of bb is inspection tools about the metadata — before the build. The only exception is bb-contents, which is a convenience, just wraps oe-pkgdata-util under the hood and tells the user the oe-pkgdata-util command in case they want to run it directly.<span class=""><br>-- <br><div class="m_9108964149688831291gmail_signature" data-smartmail="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</span></div></div>
<br>--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
<br></blockquote></div><br></div>