On Thu, 2026-07-16 at 17:20 -0600, Tom Rini wrote:
> 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.
Correct.
> Is there tooling to find and check that? And is the answer yes, we just
> ran in to it?
I'm not aware of any such tooling, it has all just been done manually so far.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#241150):
https://lists.openembedded.org/g/openembedded-core/message/241150
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]]
-=-=-=-=-=-=-=-=-=-=-=-
