Re: [OE-core] [[PATCHv3] meta: Add pam to the defaults if using systemd

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]