Re: [OE-core] [PATCH] mesa-demos: split info tools to a separate package

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Alex,

On 10/7/25 12:30 PM, Alexander Kanavin via lists.openembedded.org wrote:
> On Tue, 7 Oct 2025 at 11:36, Quentin Schulz via lists.openembedded.org
> <quentin.schulz=cherry.de@lists.openembedded.org> wrote:
>> That's making mesa-demos kind of a meta package that pulls in everything
>> built by the recipe and at the same time the only package bringing
>> binaries other than the info ones.
>>
>> Can you simply add this to the commit log/as a comment so that we can
>> remove this RDEPENDS in the future if we want to without having to guess
>> why it's there? It doesn't reflect an actual dependency but a personal
>> preference.
>>
>> We could also use RRECOMMENDS here to show it's even not required per-se
>> but we think you probably want the info packages too.
> 
> FWIW, I agree with Ross and Dmitry: preserving existing behavior is

This is personal preference. We need to do it with existing releases, 
but nothing forces us to do it with master.

I've pushed for that for linux-firmware in the past for the release 
branches, but this simply doesn't scale if we want to ever be preserving 
existing behavior. We split linux-firmware recipe into even more 
packages quite often, that's never been an issue. That's what the 
migration manuals are for, documenting changes.

Now imagine I don't actually need the mesa-demos-info package and only 
want the benchmark/test tools. Would it really be possible for me to do 
this? I don't know because of the RDEPENDS being there which seems to 
indicate at least "something" needs one of the info tools to work at 
runtime. So now I have to do research to figure out if something 
actually requires it or not.

> the right call here, and that is not a matter of personal preference.
> The patch has now merged, so anything needs to be done as followup,
> whether you want to add a comment, or split demos into
> mesa-demos-demos, and make mesa-demos an empty meta-package is up to
> you, but I'd really rather see you spend your time on high-impact
> things that matter to the project as a whole.
> 
> Such as:
> - sorting out the ungodly mess that is linux-firmware packaging (if
> the packaging subject is close to your heart)

I've read Ross (?) was working with upstream to have some packaging 
script we could call based on WHENCE or whatever else to prevent us from 
doing the error-prone task of splitting things manually like we do 
currently. I don't know if this was pursued and if it's going on.

We have someone currently adding even more packages, see 
https://lore.kernel.org/openembedded-core/20251006170804.9664-1-reatmon@ti.com/

> - solving perf reproducibility problems, which is holding up the
> upcoming release
> - writing documentation for bitbake-setup

There's currently work being done on that side. See 
https://lore.kernel.org/yocto-docs/20250819213530.3616042-1-tim.orling@konsulko.com/.

Alex, I don't appreciate the tone used in this mail. You can disagree 
with what I'm suggesting, but you can't simply say "we are not 
interested in your review, please rather send patches for these other 
issues that are more important to me" which is how I took it. We are 
already lacking reviewers, there's no need to alienate the existing ones.

Finally, this isn't (always) me nitpicking about "useless" stuff. I've 
tried to understand some changes made to some recipes (sometimes decades 
ago) to know if I can undo them or what I need to keep if I'm cleaning 
things up. mesa comes to mind a lot lately. If we don't put this 
information out there, I cannot know without spending a lot of time 
figuring it out and/or risking regressing the recipe because I 
removed/reworked something I shouldn't have.

Cheers,
Quentin