[OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

[Robert P. J. Day]

  looking for advice on how to most cleanly deal with the following.
currently working on BSP layer to which some folks want to add RPMs
that are currently (and for quite some time have been) built on a
centos 6 system, which means those RPM files are in rpm4 format; ergo,
they obviously don't play well with a system built with current OE/YP.
so ... what to do?

  first, current muttering is, "grrrrrr ... why did OE migrate to
rpm5?" i actually didn't really know the answer to that, so i poked
around and found this:

  http://rpm5.org/community/rpm-users/0998.html

the mention of "more flexibility in cross compilation and control"
makes perfect sense to me, but is there a more comprehensive writeup
somewhere that lays out the rationale for the move to rpm5 that can be
used in its defense?

  next bit of muttering is, "can we downgrade the OE build to use
rpm4-format packages?", which is not a path down which i want to walk.

  another option is to simply install a totally independent rpm5 on
the centos 6 box, and use that exclusively for building packages to be
installed on an OE system. has anyone done this? does it represent a
sane/reasonable approach?

  finally, my reaction to all of this is, "why not just write recipes
for all that software so it can be built by OE?" but, as explained to
me, the OE package build system is *heavily* tied to a much larger
internal build process that resides on the centos 6 box, and there is
a real reluctance to try to extract the OE component from the larger
build process. the phrase that seems to pop up is, "not a chance in
hell."

  so ... thoughts? short of ripping out that part of the build process
and properly adding it as additional recipes to the OE build, is it
possible to build and install rpm5 on a centos 6 box? as a test, i can
try it for my fedora 23 system and, if that works, at least i can
demonstrate proof-of-concept.

  anyone done this? if it's possible, it would seem to be the simplest
solution under the circumstances.

rday

p.s. does adding the smart package manager into all of this make any
difference? i'm pretty familiar with RPM packaging, but have barely
looked at smart, and i don't know whether it would have any relevance
to this issue.

-- 

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

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