On jeudi 6 avril 2017 15:03:36 CEST Martin Jansa wrote: > I still don't understand why not use standard update-alternatives and > install another package with your favorite openssl.conf which has higher > ALTERNATIVE_PRIORITY.
Why not, but maybe this https://bugzilla.yoctoproject.org/show_bug.cgi? id=10777 can be a stopper since libcrypto RRECOMMENDS openssl-conf > This way u-a will switch to new config even when you just install the > package which require it on the target later and will switch back to > default openssl.conf when the alternative package with config file is > uninstalled. > > On Thu, Apr 6, 2017 at 12:55 PM, Jussi Kukkonen <jussi.kukko...@intel.com> >> So previously openssl-conf package included etc/ssl/openssl.cnf and the >> symlink ${libdir}/ssl/openssl.conf. The symlink is not inside openssl-conf package but rather inside openssl. >> Nothing RDEPENDS on this package (but >> libcrypto RRECOMMENDS it). >> >> After your patch the actual configuration file is still installed. In a >> postinst >> >> * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it's for >> upgrading, then this should happen in a prerm or postrm) >> * the symlink ${libdir}/ssl/openssl.conf is created >> >> My confusion is this: how does the above solve the problem you describe? >> If you've managed to use RCONFLICTS to prevent the configuration package >> from getting included in the image, why are changes to the package needed? >> To avoid creation of the symlink inside openssl package. But I agree for the postrm/prerm tasks instead of postinst. >> >> Some alternative solutions to your problem I think might work: >> * openssl_%.bbappend with a do_install_append() that simply copies your >> conf file over the one from upstream recipe. No extra packages needed >> * BAD_RECOMMENDATIONS or PACKAGE_EXCLUDE to prevent openssl-conf from >> getting included in your image, then adding your own package with your >> configuration (does not work for dpkg I think) >> I could consider this if the patch gets reverted, but I still prefer using extra packages. It's easier this way to know which configuration has been applied (but update-alternatives could work too). TBH, I say that because I've submitted a similar series of patches for openssh based on the same principle. I think my main problem is the handling of configuration files at build time. This holds especially true for read-only rootfs where these files must be available at build time. Is there guidelines for that ? >> Jussi >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core David -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core