[[PATCHv3] meta: Add pam to the defaults if using systemd

[[PATCHv3] meta: Add pam to the defaults if using systemd

[Leon Anavi]

Add pam to DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.
This way pam will available if variable VIRTUAL-RUNTIME_init_manager
has been set to systemd. Otherwise having systemd in conjunction
with wayland but without pam leads to a conflict with the
REQUIRED_DISTRO_FEATURES for weston related recipes.

This adjustment is required following these recent changes that
switched VIRTUAL-RUNTIME_init_manager to systemd by default and added
wayland to DISTRO_FEATURES_DEFAULTS which affect "nodistro":

- 159148f4de2595556fef6e8678578df83383857b
  meta: Support opting out of any distro features
  (Please note that this commit also extended DISTRO_FEATURES_DEFAULTS
  with wayland and vulkan.)

- 0b4061c5d50261f826d0edb4b478d2d305274b7c
  conf: Switch to systemd by default and simplify init manager selection

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']

The weston recipe has pam in REQUIRED_DISTRO_FEATURES if systemd is
enabled. Therefore, it makes sense to also add pam to the defaults
through DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.

Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
---
 meta/conf/distro/include/init-manager-systemd.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/init-manager-systemd.inc b/meta/conf/distro/include/init-manager-systemd.inc
index 63fd225ca5..9460be51af 100644
--- a/meta/conf/distro/include/init-manager-systemd.inc
+++ b/meta/conf/distro/include/init-manager-systemd.inc
@@ -1,5 +1,6 @@
 # Use systemd for system initialization
 DISTRO_FEATURES:append = " systemd usrmerge"
+DISTRO_FEATURES_DEFAULTS:append = " pam"
 VIRTUAL-RUNTIME_init_manager ??= "systemd"
 VIRTUAL-RUNTIME_initscripts ??= ""
 VIRTUAL-RUNTIME_login_manager ??= "shadow-base"
-- 
2.47.3

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

[Philipp Zabel]

On Mi, 2026-07-08 at 17:37 +0300, Leon Anavi wrote:
> Add pam to DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.
> This way pam will available if variable VIRTUAL-RUNTIME_init_manager
> has been set to systemd. Otherwise having systemd in conjunction
> with wayland but without pam leads to a conflict with the
> REQUIRED_DISTRO_FEATURES for weston related recipes.

I think these requirements are partially incorrect, btw.

Weston itself only requires PAM for the VNC password, so if
PACKAGECONFIG[vnc] is disabled, there is no PAM dependency from
weston_15.0.1.bb at all, and if vnc is enabled, the PAM dependency has
nothing to do with systemd being enabled or used as init system.

The PAM dependency in weston-init.bb comes from the PAMName=weston-
autologin option in weston.service and the corresponding weston-
autologin PAM configuration. Those files are always installed if
DISTRO_FEATURES has systemd, even if VIRTUAL-RUNTIME_init_manager is
set to something else.
Shouldn't either the pam distro feature depend on the systemd distro
feature, or should the weston.service/weston-autologin files be
installed at all if the systemd distro feature is enabled but
init_manager is set to something else?
I think it wouldn't be even better to remove the PAM requirement from
weston-init if VNC is disabled, as Weston doesn't need the PAM login in
that case.

regards
Philipp

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

[Joshua Watt]

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

On Thu, Jul 9, 2026 at 2:45 AM Philipp Zabel via lists.openembedded.org
<p.zabel=pengutronix.de@lists.openembedded.org> wrote:

> On Mi, 2026-07-08 at 17:37 +0300, Leon Anavi wrote:
> > Add pam to DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.
> > This way pam will available if variable VIRTUAL-RUNTIME_init_manager
> > has been set to systemd. Otherwise having systemd in conjunction
> > with wayland but without pam leads to a conflict with the
> > REQUIRED_DISTRO_FEATURES for weston related recipes.
>
> I think these requirements are partially incorrect, btw.
>
> Weston itself only requires PAM for the VNC password, so if
> PACKAGECONFIG[vnc] is disabled, there is no PAM dependency from
> weston_15.0.1.bb at all, and if vnc is enabled, the PAM dependency has
> nothing to do with systemd being enabled or used as init system.
>
> The PAM dependency in weston-init.bb comes from the PAMName=weston-
> autologin option in weston.service and the corresponding weston-
> autologin PAM configuration. Those files are always installed if
> DISTRO_FEATURES has systemd, even if VIRTUAL-RUNTIME_init_manager is
> set to something else.
> Shouldn't either the pam distro feature depend on the systemd distro
> feature, or should the weston.service/weston-autologin files be
> installed at all if the systemd distro feature is enabled but
> init_manager is set to something else?
> I think it wouldn't be even better to remove the PAM requirement from
> weston-init if VNC is disabled, as Weston doesn't need the PAM login in
> that case.
>

I believe weston-init needs PAM regardless of VNC being enabled.

The intention of weston-init is to provide a minimal setup to start weston
on boot and not run as root (since that's a huge pain). There are
certainly other ways of starting weston (such as a login manager), but this
one has been around for a while and is nice because it "just works" even on
devices with no keyboard for (e.g. a user login in a login manager), has a
good security model (not running as root), aside from PAM has almost no
dependencies, and is quite simple. IMHO, It works well for an embedded
device because you can set the weston shell to the kiosk shell and
immediately start your application as a client to show your UI, but it's
not really great for a "desktop" experience (but I never found that a
useful experience on an embedded device outside of demonstration purposes).
It's more or less a copy of a similar system I use in my day job and I had
lofty goals of removing our version for the upstream one, but I'm beginning
to think this is an unrealistic goal.

Regardless, if we continue to use weston-init, we probably need PAM by
default - not because of weston, but because of weston-init. Alternatively,
we can do something other than weston-init, but I don't really have any
idea what that should be, what it would take to switch, or how useful it
would be in the real world.



>
> regards
> Philipp
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#240546):
> https://lists.openembedded.org/g/openembedded-core/message/240546
> Mute This Topic: https://lists.openembedded.org/mt/120174368/3616693
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> JPEWhacker@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 4807 bytes --]

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

[Leon Anavi]

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

Hi Paul, Joshua, Philipp,

Philipp, Joshua thank you for the code review and for the insights
regarding weston and weston-init. In the long term, discussing
modifications to weston and weston-init probably makes sense. However, for
the moment, I think my single-line change to add pam to the defaults is
simple and makes sense, especially considering that this fix is also
suitable for cherry-picking to release Wrynose.

Paul, following your initial code review, could you please have a look at
the third iteration of this patch? I would appreciate your feedback on
whether any additional modifications on my side are necessary to get it
merged in the upstream.

Please note that my modification through DISTRO_FEATURES_DEFAULTS targets
the nodistro and the yocto-check-layer use case. I consider this change to
be safe because in my opinion Poky or custom distributions are expected to
define an explicit DISTRO_FEATURES. So (most) other cases will remain
unaffected by this adjustment of the defaults.

Thanks, Leon

On Mon, Jul 13, 2026 at 11:30 PM Joshua Watt <jpewhacker@gmail.com> wrote:

>
>
> On Thu, Jul 9, 2026 at 2:45 AM Philipp Zabel via lists.openembedded.org
> <p.zabel=pengutronix.de@lists.openembedded.org> wrote:
>
>> On Mi, 2026-07-08 at 17:37 +0300, Leon Anavi wrote:
>> > Add pam to DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.
>> > This way pam will available if variable VIRTUAL-RUNTIME_init_manager
>> > has been set to systemd. Otherwise having systemd in conjunction
>> > with wayland but without pam leads to a conflict with the
>> > REQUIRED_DISTRO_FEATURES for weston related recipes.
>>
>> I think these requirements are partially incorrect, btw.
>>
>> Weston itself only requires PAM for the VNC password, so if
>> PACKAGECONFIG[vnc] is disabled, there is no PAM dependency from
>> weston_15.0.1.bb at all, and if vnc is enabled, the PAM dependency has
>> nothing to do with systemd being enabled or used as init system.
>>
>> The PAM dependency in weston-init.bb comes from the PAMName=weston-
>> autologin option in weston.service and the corresponding weston-
>> autologin PAM configuration. Those files are always installed if
>> DISTRO_FEATURES has systemd, even if VIRTUAL-RUNTIME_init_manager is
>> set to something else.
>> Shouldn't either the pam distro feature depend on the systemd distro
>> feature, or should the weston.service/weston-autologin files be
>> installed at all if the systemd distro feature is enabled but
>> init_manager is set to something else?
>> I think it wouldn't be even better to remove the PAM requirement from
>> weston-init if VNC is disabled, as Weston doesn't need the PAM login in
>> that case.
>>
>
> I believe weston-init needs PAM regardless of VNC being enabled.
>
> The intention of weston-init is to provide a minimal setup to start weston
> on boot and not run as root (since that's a huge pain). There are
> certainly other ways of starting weston (such as a login manager), but this
> one has been around for a while and is nice because it "just works" even on
> devices with no keyboard for (e.g. a user login in a login manager), has a
> good security model (not running as root), aside from PAM has almost no
> dependencies, and is quite simple. IMHO, It works well for an embedded
> device because you can set the weston shell to the kiosk shell and
> immediately start your application as a client to show your UI, but it's
> not really great for a "desktop" experience (but I never found that a
> useful experience on an embedded device outside of demonstration purposes).
> It's more or less a copy of a similar system I use in my day job and I had
> lofty goals of removing our version for the upstream one, but I'm beginning
> to think this is an unrealistic goal.
>
> Regardless, if we continue to use weston-init, we probably need PAM by
> default - not because of weston, but because of weston-init. Alternatively,
> we can do something other than weston-init, but I don't really have any
> idea what that should be, what it would take to switch, or how useful it
> would be in the real world.
>
>
>
>>
>> regards
>> Philipp
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#240546):
>> https://lists.openembedded.org/g/openembedded-core/message/240546
>> Mute This Topic: https://lists.openembedded.org/mt/120174368/3616693
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
>> JPEWhacker@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>

[-- Attachment #2: Type: text/html, Size: 6241 bytes --]

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

[Richard Purdie]

On Thu, 2026-07-16 at 13:02 +0300, Leon Anavi via lists.openembedded.org wrote:
> Hi Paul, Joshua, Philipp,
> 
> Philipp, Joshua thank you for the code review and for the insights
> regarding weston and weston-init. In the long term, discussing
> modifications to weston and weston-init probably makes sense.
> However, for the moment, I think my single-line change to add pam to
> the defaults is simple and makes sense, especially considering that
> this fix is also suitable for cherry-picking to release Wrynose.

I have to disagree, whilst it is a single line change, it does have
significant implications as it changes the distro feature configuration
and may require the user to take specific actions if they don't want or
need pam in their system.

Changing such a thing in an LTS release series now is not a change we
can undertake lightly. So yes, it might backport easily but that
doesn't mean it means the policy criteria.

I'm afraid we need to work out and resolve this issue properly, not
rushing a fix. I will push back harder on taking this if merging will
make it an instant backport request!

I should also highlight that as soon as I did merge this patch,
everyone would move on and do something else leaving the other
questions unresolved. That is another reason I don't think I should
merge something which I don't think is the right/complete fix.

> Paul, following your initial code review, could you please have a
> look at the third iteration of this patch? I would appreciate your
> feedback on whether any additional modifications on my side are
> necessary to get it merged in the upstream.
> 
> Please note that my modification through DISTRO_FEATURES_DEFAULTS
> targets the nodistro and the yocto-check-layer use case. I consider
> this change to be safe because in my opinion Poky or custom
> distributions are expected to define an explicit DISTRO_FEATURES. So
> (most) other cases will remain unaffected by this adjustment of the
> defaults.

That isn't the case, people can take the defaults and adjust them. They
don't expect the defaults to change underneath them.

Cheers,

Richard

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

[Philipp Zabel]

On Mo, 2026-07-13 at 14:30 -0600, Joshua Watt wrote:
> On Thu, Jul 9, 2026 at 2:45 AM Philipp Zabel via lists.openembedded.org
> <p.zabel=pengutronix.de@lists.openembedded.org> wrote:
> 
> > On Mi, 2026-07-08 at 17:37 +0300, Leon Anavi wrote:
> > > Add pam to DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.
> > > This way pam will available if variable VIRTUAL-RUNTIME_init_manager
> > > has been set to systemd. Otherwise having systemd in conjunction
> > > with wayland but without pam leads to a conflict with the
> > > REQUIRED_DISTRO_FEATURES for weston related recipes.
> > 
> > I think these requirements are partially incorrect, btw.
> > 
> > Weston itself only requires PAM for the VNC password, so if
> > PACKAGECONFIG[vnc] is disabled, there is no PAM dependency from
> > weston_15.0.1.bb at all, and if vnc is enabled, the PAM dependency has
> > nothing to do with systemd being enabled or used as init system.
> > 
> > The PAM dependency in weston-init.bb comes from the PAMName=weston-
> > autologin option in weston.service and the corresponding weston-
> > autologin PAM configuration. Those files are always installed if
> > DISTRO_FEATURES has systemd, even if VIRTUAL-RUNTIME_init_manager is
> > set to something else.
> > Shouldn't either the pam distro feature depend on the systemd distro
> > feature, or should the weston.service/weston-autologin files be
> > installed at all if the systemd distro feature is enabled but
> > init_manager is set to something else?
> > I think it wouldn't be even better to remove the PAM requirement from
> > weston-init if VNC is disabled, as Weston doesn't need the PAM login in
> > that case.
> > 
> 
> I believe weston-init needs PAM regardless of VNC being enabled.

Yes. I failed to realize weston-init relies on pam_systemd.so to set
XDG_RUNTIME_DIR (which weston needs to create the wayland socket) in
its current state. The weston.service could just as well pass it via
the environment, though, for example:

RuntimeDirectory=weston
Environment=XDG_RUNTIME_DIR=/run/weston

We've used this with an explicit socket path and WAYLAND_DISPLAY
exported via the systemd environment:

ExecStart=/usr/bin/weston --socket=${RUNTIME_DIRECTORY}/wayland-1 ...
ExecStartPost=+/usr/bin/systemctl set-environment WAYLAND_DISPLAY=${RUNTIME_DIRECTORY}/wayland-1


regards
Philipp

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

[Richard Purdie]

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?

Cheers,

Richard

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

[Tom Rini]

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.

-- 
Tom

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

[Joshua Watt]

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

On Thu, Jul 16, 2026 at 5:13 AM Philipp Zabel <p.zabel@pengutronix.de>
wrote:

> On Mo, 2026-07-13 at 14:30 -0600, Joshua Watt wrote:
> > On Thu, Jul 9, 2026 at 2:45 AM Philipp Zabel via lists.openembedded.org
> > <p.zabel=pengutronix.de@lists.openembedded.org> wrote:
> >
> > > On Mi, 2026-07-08 at 17:37 +0300, Leon Anavi wrote:
> > > > Add pam to DISTRO_FEATURES_DEFAULTS in init-manager-systemd.inc.
> > > > This way pam will available if variable VIRTUAL-RUNTIME_init_manager
> > > > has been set to systemd. Otherwise having systemd in conjunction
> > > > with wayland but without pam leads to a conflict with the
> > > > REQUIRED_DISTRO_FEATURES for weston related recipes.
> > >
> > > I think these requirements are partially incorrect, btw.
> > >
> > > Weston itself only requires PAM for the VNC password, so if
> > > PACKAGECONFIG[vnc] is disabled, there is no PAM dependency from
> > > weston_15.0.1.bb at all, and if vnc is enabled, the PAM dependency has
> > > nothing to do with systemd being enabled or used as init system.
> > >
> > > The PAM dependency in weston-init.bb comes from the PAMName=weston-
> > > autologin option in weston.service and the corresponding weston-
> > > autologin PAM configuration. Those files are always installed if
> > > DISTRO_FEATURES has systemd, even if VIRTUAL-RUNTIME_init_manager is
> > > set to something else.
> > > Shouldn't either the pam distro feature depend on the systemd distro
> > > feature, or should the weston.service/weston-autologin files be
> > > installed at all if the systemd distro feature is enabled but
> > > init_manager is set to something else?
> > > I think it wouldn't be even better to remove the PAM requirement from
> > > weston-init if VNC is disabled, as Weston doesn't need the PAM login in
> > > that case.
> > >
> >
> > I believe weston-init needs PAM regardless of VNC being enabled.
>
> Yes. I failed to realize weston-init relies on pam_systemd.so to set
> XDG_RUNTIME_DIR (which weston needs to create the wayland socket) in
> its current state. The weston.service could just as well pass it via
> the environment, though, for example:
>

It does more than that. It creates an entire user session, which does that
(among other things); I don't think just setting XDG_RUNTIME_DIR would
actually fix the problem.

weston-init is as simple as it because uses PAM+systemd to do the session
managment, which means it still behaves like a normal session (like you
would get when you login). It quite simply wouldn't work as expected
without PAM because there would be no more session. Are there session
managers that _don't_ use PAM?

Also, what's the real goal here? Do we want weston to run on startup one
way or another? If so, it probably needs a session manager of *some* kind
(weston-init being one), which will probably use PAM (even though weston
itself does not use PAM). Otherwise, the other option is to just say that
oe-core doesn't support that by default and you have to login on the
console and run weston after login (in which case, we need neither PAM nor
weston-init).


>
> RuntimeDirectory=weston
> Environment=XDG_RUNTIME_DIR=/run/weston
>
> We've used this with an explicit socket path and WAYLAND_DISPLAY
> exported via the systemd environment:
>
> ExecStart=/usr/bin/weston --socket=${RUNTIME_DIRECTORY}/wayland-1 ...
> ExecStartPost=+/usr/bin/systemctl set-environment
> WAYLAND_DISPLAY=${RUNTIME_DIRECTORY}/wayland-1
>
>
> regards
> Philipp
>

[-- Attachment #2: Type: text/html, Size: 4694 bytes --]

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

[Richard Purdie]

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.

Cheers,

Richard

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

[Joshua Watt]

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

On Thu, Jul 16, 2026 at 2:28 PM Richard Purdie via lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> 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.
>

The weird part of that (in my mind) is that maybe the compositor is
something other then weston, or weston is starting some other way than
`weston-init`, or running on something other than systemd in which case
neither weston, nor pam, nor systemd make sense to be required; the recipe
should work with any wayland compositor, regardless of how said compositor
is started (IMHO).

But, I don't think we need to change that; I would propose an easier
solution. I read through the weston source code, and it truly does only
need PAM for vnc (which is already captured in its PACKAGECONFIG).

So, the question is: Does weston actually need to RRECOMMENDS weston-init?
It's been clear from prior patches that weston-init isn't really suitable
for everyone and some would prefer something else (or nothing at all). If
we remove weston-init as a RRECOMMENDS of weston, we can also remove "pam"
from weston REQUIRED_DISTRO_FEATURES and this would also prevent it from
needing to be added to all downstream recipes. This would require users to
opt-in to weston-init if they want that as the weston autostart mechanism,
but that's probably OK; that recipe should keep pam as a
REQUIRED_DISTRO_FEATURE.


>
> Cheers,
>
> Richard
>
>
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#241108):
> https://lists.openembedded.org/g/openembedded-core/message/241108
> Mute This Topic: https://lists.openembedded.org/mt/120174368/3616693
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> JPEWhacker@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 6154 bytes --]

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

[Tom Rini]

[-- 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 --]