On Thu, Jul 16, 2026 at 2:28 PM Richard Purdie via lists.openembedded.org <[email protected]> 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 (#241109): https://lists.openembedded.org/g/openembedded-core/message/241109 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]] -=-=-=-=-=-=-=-=-=-=-=-
