[OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on Pyro

[Peter Kjellerstedt]

> -----Original Message-----
> From: Alexander Kanavin [mailto:alexander.kanavin at linux.intel.com]
> Sent: den 17 augusti 2017 12:53
> To: Mark Hatle <mark.hatle at windriver.com>; Richard Purdie
> <richard.purdie at linuxfoundation.org>; openembedded-
> core at lists.openembedded.org
> Cc: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
> Subject: Re: [OE-core] [PATCH 0/6 v2] Fix RPM4 regressions based on
> Pyro
> 
> On 08/16/2017 06:37 PM, Mark Hatle wrote:
> > Are there any examples?  I was looking there and simply didn't see
> > any.  I saw the packaging for instance exercised python interfaces, 
> > version comparison tools, etc.. but nothing that built a 
> > recipe/package and then verified the contents were 'correct'.
> >
> > Ideally the test would be to fabricate something with a known set 
> > of file dependencies, produce a package from it and then verify 
> > that the package properly included those dependencies.
> >
> > I had looked at just picking some random library out of the deploy
> > directory, and doing a pattern search on it's provides.. but I'm 
> > not sure that type of test would be very robust.
> 
> How was this regression discovered in the first place? I guess that
> some recipe used to build without error with rpm5, and stopped 
> building with rpm4. This is what you could test for: isolate the 
> problematic bit, remove everything else, and write a simple recipe(s) 
> that can be placed into meta-selftest. Then simply build those from 
> the selftest; if they build without error, you don't need to do more 
> sophisticated checks.
> 
> Alex

The problem we have, which caused me to look into this, is:

We unfortunately have a lot of unversioned libraries, e.g., 
"libfoo.so" instead of "libfoo.so.1.2.3". There is no problem 
building these (except we need to work around OE's default of 
putting *.so in ${PN}-dev rather than ${PN}). However, when rpm 
creates the packages for the applications linked with these 
libraries, it fails to automatically determine these runtime
dependencies. However, since there are no errors, what then 
happens is that the image is created, lacking most of our 
libraries, which of course leads to the image failing to boot 
when applications cannot find the libraries they need...

The reason this is not a problem with versioned libraries is 
that the code in OE has support for determining these and will 
feed that information to rpm. In hindsight, it would probably 
have been better if I looked at fixing that code to support 
unversioned libraries, but since rpm's automatic discovery of 
runtime dependencies worked in Morty, I thought it would be 
easiest to get the needed functionality back that was lost in 
the transition to dnf by fixing rpm...

//Peter