[OE-core] [PATCH] cairo: fix QA Issue
Gordan Markuš
gordan.markus at pelagicore.com
Wed Jul 5 08:52:37 UTC 2017
Acknowledged. Thanks Ross.
On 2017-07-04 13:10, Burton, Ross wrote:
> Yes, the bbappend is breaking the packaging so should fix its own mess.
>
> Ross
>
> On 4 July 2017 at 08:36, Gordan Markuš <gordan.markus at pelagicore.com
> <mailto:gordan.markus at pelagicore.com>> wrote:
>
> On 2017-07-03 15:56, Burton, Ross wrote:
>>
>> On 3 July 2017 at 13:34, Gordan Markuš
>> <gordan.markus at pelagicore.com
>> <mailto:gordan.markus at pelagicore.com>> wrote:
>>
>> -FILES_${PN}-dev += "${libdir}/cairo/*.so"
>> +FILES_${PN}-dev += "${libdir}/cairo ${libdir}/cairo/*.so"
>>
>>
>> I just spent five minutes working out *why* this fixes the QA
>> issue you were getting.
>>
>> A better fix would be to delete ${libdir}/cairo using:
>>
>> rmdir ${libdir}/cairo || :
>>
>> or
>>
>> rmdir --ignore-fail-on-non-empty ${libdir}/cairo
>>
>> (former is POSIX compliant, but I can't think of a situation where
>> that is only a hypothetical problem)
>>
>> Then in the commit message you can say that the directory is
>> always created but it only has content if you disable
>> cairo-trace. At least, I hope you are explicitly disabling
>> cairo-trace as there's no other way I can see for you go get this.
>>
>> Ross
> Thanks for the suggestion Ross, and you are right this only happens
> if there is a bbappend that removes the 'cairo-perf-utils' package.
> An example of this is the meta-ivi layer.
> Experimenting a bit it seems to me that even by adding the directory
> removal, in case it is empty, the do_package step still fails. By
> inspecting further I can observe that the directory is in fact not
> being removed but left empty which is quite puzzling.
> After doing some thinking I believe it might be better to add the
> removal of the directory and the package files in the bbappend, do
> you agree with this? Here is the PR to meta-ivi that does that
> https://github.com/GENIVI/meta-ivi/pull/45
> <https://github.com/GENIVI/meta-ivi/pull/45>.
>
>
More information about the Openembedded-core
mailing list