[oe] [meta-java][PATCH 1/3] ca-certificates-java: Fix sysconfdir for -native recipe

Yevgeny Popovych yevgenyp at pointgrab.com
Wed Sep 19 16:00:55 UTC 2018



On 09/19/2018 05:27 PM, André Draszik wrote:
> On Wed, 2018-09-19 at 12:48 +0300, Yevgeny Popovych wrote:
>>
>> On 09/17/2018 05:39 PM, André Draszik wrote:
>>> On Fri, 2018-09-07 at 21:10 +0300, Yevgeny Popovych wrote:
>>>> When ca-certificates-java-native is built, sysconfdir variable will
>>>> be set to value that includes WORKDIR.
>>>
>>> What is your use-case for a -native version of this?
>>
>> I'm glad you asked as this should answer some questions..
>>
>> I am building a package that contains prebuilt ca-certificates
>> (including what ca-certificates itself build and JKS),
>> for this package I need -native version of ca-certificates-java.
>> We have an immutable (readonly) rootfs, so running scripts at runtime is
>> not an option.
>> With patches I have recently sent it works pretty well.
>>
>> The bottom line is that there is a use-case for -native version.
>> Even if you don't have an immutable (readonly) rootfs - you might want to
>> use it
>> that way because running scripts is quite error prone.
>>
>>>
>>>> Avoid patching source with this value - use sysconfdir_native.
>>>>
>>>> Change-Id: I8ac79c3cd5016a8139d9d8c8d58bc2976d0b6fa3
>>>> Signed-off-by: Yevgeny Popovych <yevgenyp at pointgrab.com>
>>>> ---
>>>>  .../ca-certificates-java/ca-certificates-java_20180516.bb        | 9
>>>> +++++++--
>>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/recipes-core/ca-certificates-java/ca-certificates-
>>>> java_20180516.bb b/recipes-core/ca-certificates-java/ca-certificates-
>>>> java_20180516.bb
>>>> index 2db1915..7db5110 100644
>>>> --- a/recipes-core/ca-certificates-java/ca-certificates-
>>>> java_20180516.bb
>>>> +++ b/recipes-core/ca-certificates-java/ca-certificates-
>>>> java_20180516.bb
>>>> @@ -41,9 +41,14 @@ do_patch_append () {
>>>>      bb.build.exec_func('do_fix_sysconfdir', d)
>>>>  }
>>>>  
>>>> +# sysconfdir will include absolute native sysroot path in -native
>>>> builds,
>>>> avoid this
>>>> +# (see 36.24 of 
>>>> https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#faq
>>>> )
>>>> +SYSCONFDIR_VALUE_class-target = "${sysconfdir}"
>>>> +SYSCONFDIR_VALUE_class-native = "${sysconfdir_native}"
>>>> +
>>>>  do_fix_sysconfdir () {
>>>> -	sed -e 's|/etc/ssl/certs/java|${sysconfdir}/ssl/certs/java|g' \
>>>> -	    -i
>>>> ${S}/src/main/java/org/debian/security/UpdateCertificates.java
>>>> +    sed -e
>>>> 's|/etc/ssl/certs/java|${SYSCONFDIR_VALUE}/ssl/certs/java|g' \
>>>> +        -i
>>>> ${S}/src/main/java/org/debian/security/UpdateCertificates.java
>>>>  }
>>>>  
>>>
>>> No.
>>>
>>> It's probably best to remove the BBCLASSEXTEND statement in this recipe
>>> instead, as it was never tested, and is unlikely to be needed.
>>
>> We have a use-case for -native and this series fixes it.
>>
>>>
>>> The whole idea is to make this independent of the build machine paths.
>>> If
>>> you want a -native version of this, you still need to make sure to point
>>> this into the yocto sysroot. Otherwise this will try to write to the
>>> *build
>>> machine's* /etc/ directory!
>>>
>>> If you really want a -native version, you need to point this into the
>>> sysroot, and update this dynamically because of sstate usage, too.
>>
>> Ok, I suppose that ${sysconfdir_native} has mislead you -
>> it does _not_ resolve to an absolute path into native sysroot.
>> The value of ${sysconfdir_native} is always "/etc", it does not mangle in
>> any way (that's why I have used it).
> 
> Exactly, so the code in UpdateCertificates.java will try to access
> ${SYSCONFDIR_VALUE}/ssl/certs/java, i.e. /etc/ssl/certs/java, which is what
> your linux distro might or might not provide. It's not what yocto provides.

That's why we provide it with SYSROOT variable
(which is prepended to what becomes "/etc/ssl/certs/java")
because we want it to operate on a specific SYSROOT/file, not build host files.
Even if you forgot to specify SYSROOT - you are not going to screw up
your system because these files should be owned by root.

>> 
> Cheers,
> Andre'
> 
> 

-- 
Sincerely,
Yevgeny Popovych



More information about the Openembedded-devel mailing list