[OE-core] [PATCH] openssl: Fix symlink creation

[David Vincent]

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.kukkonen at 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 at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

David