* most efficient way to map perl RH rpms to OE package names? @ 2016-10-24 20:53 Robert P. J. Day 2016-10-24 21:50 ` Christopher Larson 0 siblings, 1 reply; 12+ messages in thread From: Robert P. J. Day @ 2016-10-24 20:53 UTC (permalink / raw) To: OE Core mailing list 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? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-24 20:53 most efficient way to map perl RH rpms to OE package names? Robert P. J. Day @ 2016-10-24 21:50 ` Christopher Larson 2016-10-25 6:42 ` Robert P. J. Day ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: Christopher Larson @ 2016-10-24 21:50 UTC (permalink / raw) To: Robert P. J. Day; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> 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. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics [-- Attachment #2: Type: text/html, Size: 1679 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-24 21:50 ` Christopher Larson @ 2016-10-25 6:42 ` Robert P. J. Day 2016-10-25 6:48 ` Robert P. J. Day ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Robert P. J. Day @ 2016-10-25 6:42 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 1684 bytes --] On Mon, 24 Oct 2016, Christopher Larson wrote: > > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> 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 had just started playing with oe-pkgdata-util, it obviously has a lot of equivalent functionality to your "bb", does it obsolete "bb" at this point? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-24 21:50 ` Christopher Larson 2016-10-25 6:42 ` Robert P. J. Day @ 2016-10-25 6:48 ` Robert P. J. Day 2016-10-25 7:05 ` Robert P. J. Day 2016-10-25 11:51 ` Robert P. J. Day 2016-10-25 12:11 ` Robert P. J. Day 3 siblings, 1 reply; 12+ messages in thread From: Robert P. J. Day @ 2016-10-25 6:48 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 1781 bytes --] On Mon, 24 Oct 2016, Christopher Larson wrote: > > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> 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? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-25 6:48 ` Robert P. J. Day @ 2016-10-25 7:05 ` Robert P. J. Day 2016-10-25 15:07 ` Christopher Larson 0 siblings, 1 reply; 12+ messages in thread From: Robert P. J. Day @ 2016-10-25 7:05 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 2264 bytes --] 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 <rpjday@crashcourse.ca> 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. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-25 7:05 ` Robert P. J. Day @ 2016-10-25 15:07 ` Christopher Larson 2016-10-26 3:20 ` Tim Orling ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Christopher Larson @ 2016-10-25 15:07 UTC (permalink / raw) To: Robert P. J. Day; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 2513 bytes --] On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <rpjday@crashcourse.ca> 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 < > rpjday@crashcourse.ca> 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 [-- Attachment #2: Type: text/html, Size: 3334 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-25 15:07 ` Christopher Larson @ 2016-10-26 3:20 ` Tim Orling 2016-10-26 9:48 ` Robert P. J. Day 2016-10-26 9:55 ` Robert P. J. Day 2 siblings, 0 replies; 12+ messages in thread From: Tim Orling @ 2016-10-26 3:20 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 3807 bytes --] 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 <clarson@kergoth.com> wrote: > > On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <rpjday@crashcourse.ca> > 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 < >> rpjday@crashcourse.ca> 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 > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > [-- Attachment #2: Type: text/html, Size: 5555 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-25 15:07 ` Christopher Larson 2016-10-26 3:20 ` Tim Orling @ 2016-10-26 9:48 ` Robert P. J. Day 2016-10-26 12:52 ` Robert P. J. Day 2016-10-26 9:55 ` Robert P. J. Day 2 siblings, 1 reply; 12+ messages in thread From: Robert P. J. Day @ 2016-10-26 9:48 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list ok, one more question about all this "mapping RH/CentOS rpms to Perl modules" nonsense i'm buried in, with the hope i can resolve this once and for all and finish this off, and then i can shut up about this. in brief, a current build system creates an X86-target bootable linux system by installing (among other things) a couple hundred CentOS Perl module RPMs. rather than list them all here, i took a few minutes and put them all up on a wiki page yesterday: http://www.crashcourse.ca/wiki/index.php/RPM_OE to keep track of progress. as you can see, all those RPMs (being mostly perl modules) are either x86_64 or noarch rpms, no surprise there. obviously, to convert this build system to OE/YP, i need to determine the OE recipe/package equivalent of all those rpms. i originally thought that wouldn't be so hard ... silly me. as i started poking around, i noted (as you can read in the Overview i wrote on that wiki page) that some of those modules could be found in a number of places: * part of the "perl-modules" definition when building perl itself * from the OE layer * from the meta-openembedded/meta-perl layer * from the meta-cpan layer (side note: the new target system is not x86, it's powerpc, which explains the necessity of replacing the current build system, which is x86 only and therefore unusable.) to start things off and to see how much of all that i could get into the target image during a first pass, i did the obvious: * selected "qemuppc" as the target MACHINE * added "perl-modules" to IMAGE_INSTALL to add *all* generated perl modules to the image * IMAGE_FEATURES += "package-management", to get "rpm" on the target to examine the installed rpms * built a "core-image-minimal" all that worked fine, i fired up the resulting qemuppc image and verified that it did indeed have all 639 "perl-module-*ppc7400.rpm" generated packages. overkill, yes, but i don't care at the moment. and this is where the fun starts as i now need to figure out where to get the rest. i spent a few minutes just searching the layers i mentioned above but, surely, there's an easier way. one of the absolutely crucial modules that needs to be on the target is Text::Template, but i see no existing recipe for that. more to the point, i would have thought that OE would have a mechanism to build such modules dynamically -- i thought that was the whole purpose of the "meta-cpan" layer. i was reading this linkedin page: https://www.linkedin.com/pulse/how-we-brought-cpan-embedded-devices-jens-rehsack?articleId=8774955546707699773 which refers to "automating basic package maintenance", so i assumed there was some automatic way of doing this. am i misreading that? in any event, what is the *proper* way to do this? surely it doesn't involve manually hunting down each recipe file one by one. in addition, even when i find a recipe file, it sometimes doesn't have related recipe files in the same place. case in point -- we need these two modules: * perl-Authen-PAM-0.16-16.el7.x86_64 * perl-Authen-SASL-2.15-10.el7.noarch however, the meta-perl layer contains the second, but not the first, so it's not clear to me what criteria is used to include perl module recipes in any given layer. thoughts? as a single example, how would one include the Text::Template module in a target image? any assistance gratefully received. rday p.s. i typically don't work with perl modules, so if i sound clueless about perl packaging, that's because i am. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-26 9:48 ` Robert P. J. Day @ 2016-10-26 12:52 ` Robert P. J. Day 0 siblings, 0 replies; 12+ messages in thread From: Robert P. J. Day @ 2016-10-26 12:52 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list never mind, i think i finally twigged to what i need ... i can see in the include file "perl-rdepends_5.22.1.inc" how to define a required module, such as the following "Text::*" modules: RDEPENDS_${PN}-module-text-abbrev += "${PN}-module-exporter" RDEPENDS_${PN}-module-text-balanced += "${PN}-module-carp" RDEPENDS_${PN}-module-text-balanced += "${PN}-module-exporter" RDEPENDS_${PN}-module-text-balanced += "${PN}-module-overload" RDEPENDS_${PN}-module-text-balanced += "${PN}-module-selfloader" RDEPENDS_${PN}-module-text-balanced += "${PN}-module-strict" RDEPENDS_${PN}-module-text-balanced += "${PN}-module-vars" RDEPENDS_${PN}-module-text-parsewords += "${PN}-module-carp" RDEPENDS_${PN}-module-text-parsewords += "${PN}-module-exporter" RDEPENDS_${PN}-module-text-parsewords += "${PN}-module-strict" RDEPENDS_${PN}-module-text-tabs += "${PN}-module-exporter" RDEPENDS_${PN}-module-text-tabs += "${PN}-module-strict" RDEPENDS_${PN}-module-text-tabs += "${PN}-module-vars" RDEPENDS_${PN}-module-text-wrap += "${PN}-module-exporter" RDEPENDS_${PN}-module-text-wrap += "${PN}-module-re" RDEPENDS_${PN}-module-text-wrap += "${PN}-module-strict" RDEPENDS_${PN}-module-text-wrap += "${PN}-module-text-tabs" RDEPENDS_${PN}-module-text-wrap += "${PN}-module-vars" RDEPENDS_${PN}-module-text-wrap += "${PN}-module-warnings-register" so, AFAICT, i need define only the equivalent information for additional modules i want, and explicitly add those to the list of modules i want built. seems pretty straightforward, am i overlooking anything? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-25 15:07 ` Christopher Larson 2016-10-26 3:20 ` Tim Orling 2016-10-26 9:48 ` Robert P. J. Day @ 2016-10-26 9:55 ` Robert P. J. Day 2 siblings, 0 replies; 12+ messages in thread From: Robert P. J. Day @ 2016-10-26 9:55 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 2237 bytes --] On Tue, 25 Oct 2016, Christopher Larson wrote: > On Tue, Oct 25, 2016 at 12:05 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote: > On Tue, 25 Oct 2016, Robert P. J. Day wrote: > > > 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. ah, excellent, this is important for me since, when i teach OE/YP, one of the first things i do is distinguish between a "build" and "nobuild" project directory ("nobuild" meaning configured only), and use "bb" to show how much one can query about the project before any compilation is done. this is amazingly useful. rday p.s. if readers don't know about "bb", i wrote a page on it once upon a time: http://www.crashcourse.ca/wiki/index.php/Bb i better go back and make sure it's up to date. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-24 21:50 ` Christopher Larson 2016-10-25 6:42 ` Robert P. J. Day 2016-10-25 6:48 ` Robert P. J. Day @ 2016-10-25 11:51 ` Robert P. J. Day 2016-10-25 12:11 ` Robert P. J. Day 3 siblings, 0 replies; 12+ messages in thread From: Robert P. J. Day @ 2016-10-25 11:51 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list following up on my original query, i'm now in the process of "mapping" a couple hundred CentOS perl rpms to their OE equivalents, and here's the process so far; just want to check that i'm going about this in a sane way. first, as chris larson suggested, use "oe-pkgdata-util" to see which generated perl modules appear to match up to equivalent rpms, and quite a number of them seem to be direct equivalents, such as: * perl-HTTP-Tiny-0.033-3.el7.noarch * perl-module-http-tiny so examples like that appear pretty straightforward. next, i noticed that there are a few perl recipes under OE, recipes-devtools and recipes-extended, a couple *apparent* equivalents: * perl-XML-LibXML-2.0018-5.el7.x86_64 * libxml-perl_0.08.bb * perl-XML-NamespaceSupport-1.11-10.el7.noarch * libxml-namespacesupport-perl_1.11.bb and so on. not so many of those but still, that took care of a few more matches. finally, i figure i'm going to have to dive into meta-cpan for the rest, and here's something puzzling. one of the RH rpms to be matched was perl-IO-Compress-2.061-2.el7.noarch, but the generated modules were: perl-module-io-compress-deflate perl-module-io-compress-adapter-bzip2 perl-module-io-compress-zlib-extra perl-module-io-compress-zip-constants perl-module-io-compress-bzip2 perl-module-io-compress-adapter-identity perl-module-io-compress-zlib-constants perl-module-io-compress-base-common perl-module-io-compress-adapter-deflate perl-module-io-compress-gzip perl-module-io-compress-zip perl-module-io-compress-gzip-constants perl-module-io-compress-base perl-module-io-compress-rawdeflate but no "perl-module-io-compress", which is what i would have expected. however, if i pop over to meta-cpan, there *is* a recipe file "io-compress-perl_2.069.bb". can anyone explain how i should interpret this? it seems (and i am not a perl expert) that the foundation IO::Compress recipe is at meta-cpan, but the more specific sub-modules are built from the base OE perl recipe. or is it that these modules: perl-module-io-compress-base-common perl-module-io-compress-base represent the base class? i'm just trying to figure out the standard OE packaging for perl modules. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: most efficient way to map perl RH rpms to OE package names? 2016-10-24 21:50 ` Christopher Larson ` (2 preceding siblings ...) 2016-10-25 11:51 ` Robert P. J. Day @ 2016-10-25 12:11 ` Robert P. J. Day 3 siblings, 0 replies; 12+ messages in thread From: Robert P. J. Day @ 2016-10-25 12:11 UTC (permalink / raw) To: Christopher Larson; +Cc: OE Core mailing list one more question on this topic before i dive back in ... it seems that some perl modules are available as both a perl recipe-generated module, and from meta-cpan. generated module: perl-module-compress-raw-bzip2 meta-cpan recipe: compress-raw-bzip2-perl_2.069.bb am i reading correctly that those should represent the same thing, and that (theoretically) i could include either equivalently? ok, back to work ... rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-10-26 12:54 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-24 20:53 most efficient way to map perl RH rpms to OE package names? Robert P. J. Day 2016-10-24 21:50 ` Christopher Larson 2016-10-25 6:42 ` Robert P. J. Day 2016-10-25 6:48 ` Robert P. J. Day 2016-10-25 7:05 ` Robert P. J. Day 2016-10-25 15:07 ` Christopher Larson 2016-10-26 3:20 ` Tim Orling 2016-10-26 9:48 ` Robert P. J. Day 2016-10-26 12:52 ` Robert P. J. Day 2016-10-26 9:55 ` Robert P. J. Day 2016-10-25 11:51 ` Robert P. J. Day 2016-10-25 12:11 ` Robert P. J. Day
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.