On Thu, Jul 16, 2026 at 09:28:26PM +0100, Richard Purdie wrote: > On Thu, 2026-07-16 at 12:27 -0600, Tom Rini wrote: > > On Thu, Jul 16, 2026 at 12:25:00PM +0100, Richard Purdie wrote: > > > On Wed, 2026-07-08 at 17:37 +0300, Leon Anavi via > > > lists.openembedded.org wrote: > > > > This fixes issues with test_machine_world when running the > > > > yocto-check-layer script for BSP layers that include weston in > > > > the > > > > dependency chain, for example meta-tegra: > > > > > > > > ERROR: Required build target 'meta-world-pkgdata' has no > > > > buildable > > > > providers. > > > > Missing or unbuildable dependency chain was: ['meta-world- > > > > pkgdata', > > > > 'l4t-graphics-demos', 'weston'] > > > > > > Why wouldn't l4t-graphics-demos just list pam as a required distro > > > feature for that recipe? > > > > Because it doesn't come from l4t-graphics-demos it comes from weston? > > And l4t-graphics-demos supports wayland or x11. Doing something here > > would be the not satisfying approach Paul mentioned on v1 or so of > > this thread. It shuts yocto-check-layer up while doing nothing of > > value. > > I should explain a little about the unfortunate way that > REQUIRED_DISTRO_FEATURES works. > > Anything that needs a specific distro feature uses that but it has a > unfortunate ripple side effect where anything with that recipe as a > dependency, must also then have the same REQUIRED_DISTRO_FEATURES line > (or more restrictive). > > This was discussed extensively in the past and you will see this in the > way x11 is rippled through recipes. > > I appreciate you will then argue this should be automatic as obviously > anything depending on X will require Y as a DISTRO_FEATURE. I have > refused to implement any such magic as it turns out it can misfire > spectacularly badly and end up just masking every recipe out as a > ripple effect for a poorly thought out change as the worst case > scenario. There are plenty of scenarios where unexpected bad things can > happen which would be hard to spot. This was discussed in the past too. > > So, my point is that if you have weston-init as a dependency, even > indirectly, you have the required distro features requirement passed to > that recipe and need to mark the recipe as such. > > No, it isn't great, but the alternatives can go spectacularly wrong too > and you can't work out how to do this correctly automatically in a safe > way. > > You are doing something of value, you're clearly marking the > requirement of the recipe (which it has via it's dependencies). > > I think the question is marking the recipe in question to say it > requires "pam+systemd+weston" or "x11", which might mean anonymous > python but is definitely doable.
This specific problem has (will be) fixed in meta-tegra since weston can
just be dropped. But if I follow what you're saying right, since
meta/recipes-graphics/wayland/weston_15.0.0.bb ends up with:
REQUIRED_DISTRO_FEATURES = "wayland opengl
${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager', 'systemd', 'pam', '',
d)}"
essentially every recipe that has DEPENDS on a PACKAGECONFIG that
brings in weston *also* needs that same logic, to not run in to a
problem later on.
Is there tooling to find and check that? And is the answer yes, we just
ran in to it?
--
Tom
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#241110): https://lists.openembedded.org/g/openembedded-core/message/241110 Mute This Topic: https://lists.openembedded.org/mt/120174368/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
