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

Mark Hatle mark.hatle at windriver.com
Thu Aug 17 14:37:43 UTC 2017


On 8/17/17 5:53 AM, Alexander Kanavin wrote:
> 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.
> 

In -my- case (I can't speak for Peter), I found the issue trying to build SRPMs
on the target.  I either ran into dep problems or could not install what I built.

Further I went in and simply looked at the output (deploy dir):  rpm -qp
<package> --provides

I was able to quickly determine that only OE style dependencies were present.

So from a test perspective, we probably need to build something with a known
content and run rpmdeps against it, and then build a package (recipe) and verify
the dependencies are there as well.  I just don't know how to implement that in
the existing unit-test framework.

--Mark

> Alex
> 




More information about the Openembedded-core mailing list