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

Martin Jansa martin.jansa at gmail.com
Thu Apr 6 13:03:36 UTC 2017


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.

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>
wrote:

> On 6 April 2017 at 12:23, David Vincent <freesilicon at gmail.com> wrote:
> >
> > On mercredi 5 avril 2017 09:30:52 CEST Jussi Kukkonen wrote:
> > > This apparently breaks key generation with openssl-native because the
> file
> > > doesn't exist.
> >
> > Looking at the recipe right now, I understand why key generation is
> broken for
> > native build (I should have been more careful). I see two ways of fixing
> it :
> >         - either recreate the symlink in do_install_append_class_native
> >         - or simply modifiyng the OPENSSL_CONF variable in the same task.
> >
> > >
> > > I can fix it by adding one more complication to the recipe (will send a
> > > patch) but I don't think the current solution is all that great: I've
> been
> > > looking at this patch for a while now and still don't really
> understand why
> > > it is needed and how these different packages interact. I'm sure it
> makes
> > > sense when you look at the other recipe but ... isn't it a bad sign
> that
> > > that context seems to be needed?
> >
> > OK, I will provide some context because maybe my approach was wrong. In
> some
> > of my builds, I require some images to have a very specific
> configuration to
> > make OpenSSL use engines. My idea was to provide a package for this task
> since
> > the default file can not be overridden (and in fact shouldn't be for the
> native
> > build).
>
>
> 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).
>
> 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?
>
>
>
> 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)
>
> Jussi
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170406/c144c67d/attachment-0002.html>


More information about the Openembedded-core mailing list