Re: [PATCH] openssl: Fix symlink creation

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

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 <jussi.kukkonen@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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]