[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Richard Purdie]

On Tue, 2017-05-09 at 10:31 +0200, Patrick Ohly wrote:
> Hello!
> 
> One of the goals of the revised "Yocto Compatible 2.0" is to increase
> the reuse of layers. One aspect of that is that merely adding a layer
> should not change a build unless content or features of that layer
> are explicitly enabled in the build. That way, a project can add
> multiple layers and then decide based on the configuration what is
> getting built and how.
> 
> There's already a test for this based on task signatures for BSP and
> distro layers in the yocto-compat-layer.py test tool. Should the same
> test also be enabled for software layers, i.e. should *all* layers
> avoid changing signatures? I think so, because that was the original
> goal and in particular software layers should add recipes, not change
> existing ones.
>
> There's just one practical problem with this: how can a distro or
> software layer introduce a new distro or build-time feature that
> affects existing recipes without changing signatures? Or is the check
> to strict and we somehow need to allow exceptions?

For what its worth, I do think we need to do this. Adding layers
shouldn't (IMO) on its own change what gets built or how its
configured, the user should have to opt into that somehow.

As you mention, there are some practicality issues associated with
that. If this means we need to improve the technology we're using to
handle those issues I'd be very open to that.

> Consider this example (from the IoT Refkit firewall feature).
> recipes-security/openssh/openssh_%.bbappend:
> 
>         FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>         
>         RDEPENDS_${PN}-sshd += "iptables"
>         
>         SRC_URI_append = "\
>             file://${PN}-ipv4.conf \
>             file://${PN}-ipv6.conf \
>         "
>         
>         do_install_append() {
>             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} += " \
>             ${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)} \
>         "
>         
> Clearly this isn't "Yocto Compatible 2.0", because merely adding the
> layer which has this .bbappend changes how openssh is built.

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?

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

Cheers,

Richard