[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

On Tue, 2017-05-09 at 09:42 +0100, Richard Purdie wrote:
> I believe its possible to do this in a slightly neater way than your
> example using existing techniques such as distro overrides:
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> RDEPENDS_${PN}-sshd_append_refkit-firewall = " iptables"
> 
> SRC_URI_append_refkit-firewall = "\
>              file://${PN}-ipv4.conf \
>              file://${PN}-ipv6.conf \
> "
> 
> do_install_append_refkit-firewall() {
> 	install -d ${D}${systemd_unitdir}/system/sshd.socket.d
> 	install -m 0644 ${WORKDIR}/${PN}-ipv4.conf ${D}${systemd_unitdir}/system/sshd.socket.d
> 	if ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', 'true', 'false', d)}; then
> 		install -m 0644 ${WORKDIR}/${PN}-ipv6.conf ${D}${systemd_unitdir}/system/sshd.socket.d
>         fi
> }
> 
> FILES_${PN}_append_refkit-firewall = " \
>     ${systemd_unitdir}/system/sshd.socket.d/${PN}-ipv4.conf \
>     ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', \
>    '${systemd_unitdir}/system/sshd.socket.d/${PN}-ipv6.conf', '', d)} \
> "
> 
> To enable this you'd set something like:
> 
> DISTROOVERRIDES .= ":refkit-firewall"
> 
> It would mean more distro overrides than we've commonly used so far
> however that shouldn't be too much of an issue?

I've done something similar when enabling Smack. The downside was that
one also wants a corresponding DISTRO_FEATURE, and then both overrides
and DISTRO_FEATURE have to be set consistently. It isn't possible to
just set the DISTRO_FEATURE and then set the override based on that
automatically, so the traditional way of choosing distro features no
longer works.

Perhaps
  DISTRO_FEATURE_append_refkit-firewall = " refkit-firewall"
can address that.

> How does the above look as a general mechanism to promote?

I guess it'll work. It passes the yocto-compat-layer.py test.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.