Robert, You did not mention meta-perl: http://git.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl
The perl modules in meta-perl follow Debian naming: https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html https://anonscm.debian.org/cgit/?q=perl 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. 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. Not an ideal situation, but we have similar issues with python modules. Cheers. --Tim On Tue, Oct 25, 2016 at 8:07 AM, Christopher Larson <[email protected]> wrote: > > On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <[email protected]> > wrote: > >> On Tue, 25 Oct 2016, Robert P. J. Day wrote: >> >> > On Mon, 24 Oct 2016, Christopher Larson wrote: >> > >> > > >> > > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day < >> [email protected]> wrote: >> > > i've just been handed a list of about 200 perl packages by >> their >> > > centos rpm names, and i want to map most, if not all, of them >> to their >> > > equivalent OE package names. >> > > >> > > my first instinct (based on not having used a lot of perl OE >> > > packages) is to add both "perl" and "perl-modules" to >> IMAGE_INSTALL, >> > > just to fetch and build every possible module available through >> the OE >> > > perl recipe -- that will at least give me an idea of what's >> available. >> > > >> > > next, i can see the pattern in some OE package names -- i've >> > > verified that the Time::HiRes package is available in OE as >> > > perl-module-time-hires, which i assume is part of the dynamic >> naming >> > > being done in perl_5.22.1.bb. >> > > >> > > am i approaching this the right way? >> > > >> > > >> > > Could also bitbake perl, then use oe-pkgdata-util to locate the >> > > actual perl modules in the packages, i.e. */Time/HiRes.pm. >> > >> > i once wrote a wiki page on "bb", distinguishing between queries >> > you could make before you did a build, versus queries that needed a >> > build. it seems like oe-pkgdata-util needs a completed build for >> > pretty much everything, do i have that right? >> >> never mind, i just read this snippet from the YP ref manual: >> >> "You can use the oe-pkgdata-util command-line utility to query >> PKGDATA_DIR and display various package-related information. When you >> use the utility, you must use it to view information on packages that >> have already been built." >> >> so i'm assuming that means for *all* oe-pkgdata subcommands, no >> exceptions. > > > 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. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
