[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