[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

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?

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.

But introducing a "refkit-firewall" DISTRO_FEATURE just makes
the .bbappend horrible to read (because the feature must be checked in
multiple places) and still fails the "signature unchanged" test, because
now the signature includes at least the new condition that is tested for
plus (optionally) helper variables. I don't see a way around this.

FWIW, here's the hacky replacement for the .bbappend above (probably
could be written better, but IMHO not without changing signatures):

        FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
        
        RDEPENDS_${PN}-sshd += "${@bb.utils.contains('DISTRO_FEATURES', 'refkit-firewall', 'iptables', '', d)}"
        
        SRC_URI_REFKIT_FIREWALL = "\
            file://${PN}-ipv4.conf \
            file://${PN}-ipv6.conf \
        "
        SRC_URI_append = "${@bb.utils.contains('DISTRO_FEATURES', 'refkit-firewall', '${SRC_URI_REFKIT_FIREWALL}', '', d)}"
        
        install_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
        }
        do_install_append = "${@bb.utils.contains('DISTRO_FEATURES', 'refkit-firewall', d.getVar('install_refkit_firewall', False), '', d)}"
        
        FILES_PN_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)} \
        "
        FILES_${PN} .= "${@bb.utils.contains('DISTRO_FEATURES', 'refkit-firewall', d.getVar('FILES_PN_REFKIT_FIREWALL', False), '', d)}"

What works is to put the changes into a .inc file instead of using
a .bbappend. But that is more complex, and begs the question in which
cases a .bbappend file is still the right choice?

-- 
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.