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

[Mark Hatle]

On 8/17/17 8:01 AM, Peter Kjellerstedt wrote:
>> -----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 

You shouldn't have to version, but you do need to declare an soname.  (This can
be done after link as well if I remember correctly.)  Once an soname is declared
in your library, OE will know that it's runtime and not -dev.)

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

It might be a good idea to have an optional QA warning for unversioned
libraries.  Last time I looked (a few years ago) we didn't have any by default.
This made it easy to define the rules that we use the declared soname(s) to
define what goes into the runtime library package and what goes into the -dev
package.

--Mark

> //Peter
>