| Message ID | 20251002015030.2464972-1-dmitry.baryshkov@oss.qualcomm.com |
|---|---|
| State | Accepted, archived |
| Commit | 153e33193b51868768e86be9a1d17b25b25f346a |
| Headers | show |
| Series | mesa-demos: split info tools to a separate package | expand |
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
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
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.
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
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
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
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 \
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(+)