All of lore.kernel.org
 help / color / mirror / Atom feed
* [meta-arago][master][discussion] Qt package groups and config locations
@ 2025-01-24 21:54 Randolph Sapp
  2025-01-24 23:14 ` Ryan Eatmon
  0 siblings, 1 reply; 3+ messages in thread
From: Randolph Sapp @ 2025-01-24 21:54 UTC (permalink / raw)
  To: denis, reatmon, afd, c-shilwant; +Cc: meta-arago

Hey,

Asking for some general advice before I submit the next series. Cleaning up
meta-qt* package groups and everything there is a bit of a logistical argument
to be made.

We now have an official requirement tracking Qt6 enablement which means more
automated testing. At the same time I do not think meta-arago should be
inherently dependent on a layer as heavy as meta-qt*. I'm planning on making a
series of isolated package groups and configs that can be toggled through a
distro feature.

Where do we think this should belong? The distro layer or the extras layer? I'm
leaning toward the distro layer as these are ultimately distro specific configs,
but I can understand that some may believe this is inherently "extra" content.
Regardless, the test layer will need to be updated to point to this.

Maybe it should be a generic "software" layer? I don't like splitting things
unnecessarily, but this is a weird example where we need certain features
enabled for both testing and release, but it doesn't really make sense to
duplicate it. No clue. Any opinions?

Regards,
Randolph


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [meta-arago][master][discussion] Qt package groups and config locations
  2025-01-24 21:54 [meta-arago][master][discussion] Qt package groups and config locations Randolph Sapp
@ 2025-01-24 23:14 ` Ryan Eatmon
  2025-01-25  0:10   ` Randolph Sapp
  0 siblings, 1 reply; 3+ messages in thread
From: Ryan Eatmon @ 2025-01-24 23:14 UTC (permalink / raw)
  To: Randolph Sapp, denis, afd, c-shilwant; +Cc: meta-arago



On 1/24/2025 3:54 PM, Randolph Sapp wrote:
> Hey,
> 
> Asking for some general advice before I submit the next series. Cleaning up
> meta-qt* package groups and everything there is a bit of a logistical argument
> to be made.
> 
> We now have an official requirement tracking Qt6 enablement which means more
> automated testing. At the same time I do not think meta-arago should be
> inherently dependent on a layer as heavy as meta-qt*. I'm planning on making a
> series of isolated package groups and configs that can be toggled through a
> distro feature.
> 
> Where do we think this should belong? The distro layer or the extras layer? I'm
> leaning toward the distro layer as these are ultimately distro specific configs,
> but I can understand that some may believe this is inherently "extra" content.
> Regardless, the test layer will need to be updated to point to this.
> 
> Maybe it should be a generic "software" layer? I don't like splitting things
> unnecessarily, but this is a weird example where we need certain features
> enabled for both testing and release, but it doesn't really make sense to
> duplicate it. No clue. Any opinions?

Could it be argued that these are demos?  And maybe should be in 
meta-arago-demos?

What all software are we talking about being dependent on qt6?


> Regards,
> Randolph

-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [meta-arago][master][discussion] Qt package groups and config locations
  2025-01-24 23:14 ` Ryan Eatmon
@ 2025-01-25  0:10   ` Randolph Sapp
  0 siblings, 0 replies; 3+ messages in thread
From: Randolph Sapp @ 2025-01-25  0:10 UTC (permalink / raw)
  To: Ryan Eatmon, denis, afd, c-shilwant; +Cc: meta-arago

On Fri Jan 24, 2025 at 5:14 PM CST, Ryan Eatmon wrote:
> On 1/24/2025 3:54 PM, Randolph Sapp wrote:
> > Hey,
> > 
> > Asking for some general advice before I submit the next series. Cleaning up
> > meta-qt* package groups and everything there is a bit of a logistical argument
> > to be made.
> > 
> > We now have an official requirement tracking Qt6 enablement which means more
> > automated testing. At the same time I do not think meta-arago should be
> > inherently dependent on a layer as heavy as meta-qt*. I'm planning on making a
> > series of isolated package groups and configs that can be toggled through a
> > distro feature.
> > 
> > Where do we think this should belong? The distro layer or the extras layer? I'm
> > leaning toward the distro layer as these are ultimately distro specific configs,
> > but I can understand that some may believe this is inherently "extra" content.
> > Regardless, the test layer will need to be updated to point to this.
> > 
> > Maybe it should be a generic "software" layer? I don't like splitting things
> > unnecessarily, but this is a weird example where we need certain features
> > enabled for both testing and release, but it doesn't really make sense to
> > duplicate it. No clue. Any opinions?
>
> Could it be argued that these are demos?  And maybe should be in 
> meta-arago-demos?
>
> What all software are we talking about being dependent on qt6?

These are applications provided as recipes directly from meta-qt*. The only
thing being carried here will be packagegroups for testing and configs for the
distro if meta-qt6 is enabled.

Which I guess means that the packagegroups should be listed in meta-arago-test
and the configs should be in meta-arago-distro?

A specific example would be hellogles which is shipped as part of
qtbase-examples. Ideally for testing we'll want to execute that with the eglfs
and wayland backend, which will require enabling the packageconfig "kms gbm
gles2 eglfs examples" on the qtbase package.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-01-25  0:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-24 21:54 [meta-arago][master][discussion] Qt package groups and config locations Randolph Sapp
2025-01-24 23:14 ` Ryan Eatmon
2025-01-25  0:10   ` Randolph Sapp

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.