<div dir="ltr">On 6 April 2017 at 12:23, David Vincent &lt;<a href="mailto:freesilicon@gmail.com">freesilicon@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt; On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:<br>&gt; &gt; This apparently breaks key generation with openssl-native because the file<br>&gt; &gt; doesn&#39;t exist.<br>&gt;<br>&gt; Looking at the recipe right now, I understand why key generation is broken for<br>&gt; native build (I should have been more careful). I see two ways of fixing it :<br>&gt;         - either recreate the symlink in do_install_append_class_native<br>&gt;         - or simply modifiyng the OPENSSL_CONF variable in the same task.<br>&gt;<br>&gt; &gt;<br>&gt; &gt; I can fix it by adding one more complication to the recipe (will send a<br>&gt; &gt; patch) but I don&#39;t think the current solution is all that great: I&#39;ve been<br>&gt; &gt; looking at this patch for a while now and still don&#39;t really understand why<br>&gt; &gt; it is needed and how these different packages interact. I&#39;m sure it makes<br>&gt; &gt; sense when you look at the other recipe but ... isn&#39;t it a bad sign that<br>&gt; &gt; that context seems to be needed?<br>&gt;<br>&gt; OK, I will provide some context because maybe my approach was wrong. In some<br>&gt; of my builds, I require some images to have a very specific configuration to<br>&gt; make OpenSSL use engines. My idea was to provide a package for this task since<br>&gt; the default file can not be overridden (and in fact shouldn&#39;t be for the native<br>&gt; build).<br><br><br>So previously openssl-conf package included etc/ssl/openssl.cnf and the symlink ${libdir}/ssl/openssl.conf. Nothing RDEPENDS on this package (but libcrypto RRECOMMENDS it). <br><br>After your patch the actual configuration file is still installed. In a postinst<br>  * ${libdir}/ssl/openssl.conf is removed if it exists (why? If it&#39;s for upgrading, then this should happen in a prerm or postrm)<br>  * the symlink ${libdir}/ssl/openssl.conf is created<div><br>My confusion is this: how does the above solve the problem you describe? If you&#39;ve managed to use RCONFLICTS to prevent the configuration package from getting included in the image, why are changes to the package needed?<br><br><br><br>Some alternative solutions to your problem I think might work:<br>* openssl_%.bbappend with a do_install_append() that simply copies your conf file over the one from upstream recipe. No extra packages needed<br>* 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)<br><br>Jussi</div></div>