On Fri, Apr 07, 2017 at 02:27:45PM +0200, David Vincent wrote: > 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
Why would it be a stopper? With u-a you can have any number of the u-a alternative providers installed in the image at the same time. > > 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 <[email protected]> > >> 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 > >> [email protected] > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > David -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
