[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