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

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

[Dmitry Baryshkov]

While the rest of programs inside mesa-demos are really "demos", several
*info utilities have separate value as they allow gathering information
about the running system in a manner similar to clinfo or vulkaninfo.
Split them into a separate package in order to allow picking them info
the images without picking up the rest of "demos".

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb b/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb
index a9e84039d2c9..0bc8519e90e2 100644
--- a/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb
@@ -20,6 +20,10 @@ REQUIRED_DISTRO_FEATURES = "opengl x11"
 
 EXTRA_OEMESON = "-Dwith-system-data-files=true"
 
+PACKAGE_BEFORE_PN = "${PN}-info"
+RDEPENDS:${PN} += " ${PN}-info"
+FILES:${PN}-info = "${bindir}/*info"
+
 # Note: wayland is not included as the feature requires libdecor recipe,
 # which is not currently in core
 PACKAGECONFIG ?= "drm egl gles1 gles2 \
-- 
2.47.3

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

[Quentin Schulz]

Hi Dmitry,

On 10/2/25 3:50 AM, Dmitry Baryshkov via lists.openembedded.org wrote:
> While the rest of programs inside mesa-demos are really "demos", several
> *info utilities have separate value as they allow gathering information
> about the running system in a manner similar to clinfo or vulkaninfo.
> Split them into a separate package in order to allow picking them info
> the images without picking up the rest of "demos".
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>   meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb b/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb
> index a9e84039d2c9..0bc8519e90e2 100644
> --- a/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb
> +++ b/meta/recipes-graphics/mesa/mesa-demos_9.0.0.bb
> @@ -20,6 +20,10 @@ REQUIRED_DISTRO_FEATURES = "opengl x11"
>   
>   EXTRA_OEMESON = "-Dwith-system-data-files=true"
>   
> +PACKAGE_BEFORE_PN = "${PN}-info"
> +RDEPENDS:${PN} += " ${PN}-info"

Is there really a dependency from demo applications on the various info 
binaries?

Can you justify this dependency?

Otherwise this looks good to me.

Cheers,
Quentin

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

[Ross Burton]

On 6 Oct 2025, at 15:01, Quentin Schulz via lists.openembedded.org <quentin.schulz=cherry.de@lists.openembedded.org> wrote:
> 
> Is there really a dependency from demo applications on the various info binaries?
> 
> Can you justify this dependency?
> 
> Otherwise this looks good to me.

I’m not Dmitry, but I’d imagine so that if you install mesa-demos you get _all_ of mesa-demos, but you can just install mesa-demos-info for just the info tools if desired.

Ross

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

[Dmitry Baryshkov]

On 06/10/2025 19:39, Ross Burton wrote:
> On 6 Oct 2025, at 15:01, Quentin Schulz via lists.openembedded.org <quentin.schulz=cherry.de@lists.openembedded.org> wrote:
>>
>> Is there really a dependency from demo applications on the various info binaries?
>>
>> Can you justify this dependency?
>>
>> Otherwise this looks good to me.
> 
> I’m not Dmitry, but I’d imagine so that if you install mesa-demos you get _all_ of mesa-demos, but you can just install mesa-demos-info for just the info tools if desired.

Exactly. The distros / users might be pulling mesa-demos and expecting 
both kinds of apps. Let's not disappoint them.

-- 
With best wishes
Dmitry

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

[Quentin Schulz]

On 10/6/25 10:51 PM, Dmitry Baryshkov wrote:
> On 06/10/2025 19:39, Ross Burton wrote:
>> On 6 Oct 2025, at 15:01, Quentin Schulz via lists.openembedded.org 
>> <quentin.schulz=cherry.de@lists.openembedded.org> wrote:
>>>
>>> Is there really a dependency from demo applications on the various 
>>> info binaries?
>>>
>>> Can you justify this dependency?
>>>
>>> Otherwise this looks good to me.
>>
>> I’m not Dmitry, but I’d imagine so that if you install mesa-demos you 
>> get _all_ of mesa-demos, but you can just install mesa-demos-info for 
>> just the info tools if desired.
> 
> Exactly. The distros / users might be pulling mesa-demos and expecting 
> both kinds of apps. Let's not disappoint them.
> 

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.

Cheers,
Quentin

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

[Alexander Kanavin]

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
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)
- solving perf reproducibility problems, which is holding up the
upcoming release
- writing documentation for bitbake-setup
- or any other items that you can find in weekly status reports.

Alex

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

[Quentin Schulz]

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