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 <[email protected]> >>>> --- >>>> .../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 -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
