[OE-core] most efficient way to map perl RH rpms to OE package names?

Robert P. J. Day rpjday at crashcourse.ca
Wed Oct 26 09:48:24 UTC 2016


  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
========================================================================




More information about the Openembedded-core mailing list