[oe] [meta-java][PATCH 0/3] ca-certificates-java: Fix usage as a native tool, do_rootfs failure

[Yevgeny Popovych]

Hi Andre,

Thanks for the feedback!


On 09/17/2018 06:10 PM, André Draszik wrote:
> On Fri, 2018-09-07 at 21:10 +0300, Yevgeny Popovych wrote:
>> This series fixes several issues with ca-certificates-java:
>> * when used as a native tool
>> * failure on do_rootfs
> 
> Can you share complete logs? I'd like to understand the do_rootfs issues you
> are seeing (I don't see any).

The issue is that during do_rootfs, ca-certificates postinst calls
ca-certificates-java hook and the hook fails. (didn't save the log, sorry)
This is what patch #2 tries to fix (ca-certificates-java: Don't fail when called via hook on do_rootfs).

Richard also saw this issue when he tried another patch
(http://lists.openembedded.org/pipermail/openembedded-devel/2018-August/120066.html).
Although that doesn't matter IMO, I am using deb `PACKAGE_CLASSES`,
and Richard supposedly uses ipk (the default one).

> 
>> This doesn't fix all the issues and there is definitely a room for
>> improvement.
> 
> What other issues?

At least the use case for the target (the one mentioned below) and
some postinst issues that may appear (didn't test that).

> 
>> I presume that running it on the target doesn't work - at least
>> ${sysconfdir} is
>> not expanded in the hook.
> 
> True.
> 
>> I also think that will be best to drop create-ca-certificates-java usage
>> in
>> the postinst and let it be called as a hook of ca-certificates. This will
>> allow
>> us to remove some code and simplify both script and recipe.
> 
> You can't do that, because ca-certificates could be installed before ca-
> certificates-java. In which case the hook will not be run.

This can't really happen.
In OE, all packages are first unpacked and only then, in a separate step, the postinst are run.
This means that during do_rootfs, ca-certificates will always have the java hook present.

In addition to that, having the empty postinst in ca-certificates-java is desirable
for target/runtime because on upgrades, the hook should be run by ca-certificates
and our ca-certificates-java package should do nothing in this case.
What I mean is that the package should just be a way to deliver the hook.

> 
>>
>> It would be great if others could test their use cases;
>> and clarify them - is create-ca-certificates-java really needed?.
> 
> As per above.
> 
> Cheers,
> Andre'
> 
>>
>> Yevgeny Popovych (3):
>>   ca-certificates-java: Fix sysconfdir for -native recipe
>>   ca-certificates-java: Don't fail when called via hook on do_rootfs
>>   ca-certificates-java: Distinguish between SYSROOT and D
>>
>>  .../ca-certificates-java.hook.in                   | 23 +++++++++++----
>> -------
>>  .../ca-certificates-java_20180516.bb               | 11 ++++++++---
>>  2 files changed, 19 insertions(+), 15 deletions(-)
>>
>> -- 
>> 2.7.4
>>
> 

-- 
Sincerely,
Yevgeny Popovych