Re: [OE-core] [PATCH 2/2] gstreamer1.0-plugins-good: add qt5 PACKAGECONFIG

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Sun, 2020-04-12 at 14:46 -0400, Denys Dmytriyenko wrote:
> On Tue, Mar 24, 2020 at 10:37:25PM +0000, Richard Purdie wrote:
> > On Tue, 2020-03-24 at 18:12 -0400, Denys Dmytriyenko wrote:
> > > On Tue, Mar 24, 2020 at 07:57:27PM +0000, Richard Purdie wrote:
> > > > On Tue, 2020-03-24 at 15:32 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Mar 24, 2020 at 07:29:42PM +0000, Richard Purdie
> > > > > wrote:
> > > > > > On Tue, 2020-03-24 at 14:43 -0400, Denys Dmytriyenko wrote:
> > > All I could find is OE TSC minutes from 7 May 2013 referring to
> > > some
> > > related 
> > > list discussion:
> > > 
> > > https://lists.openembedded.org/g/tsc/message/369?p=,,,20,0,0,0::Created,,PACKAGECONFIG,20,2,0,72188707
> > > 
> > > (9:47:21 AM) RP: bluelightning: I think this was to PACKAGECONFIG
> > > more recipes
> > > (9:47:28 AM) bluelightning: ah ok
> > > (9:47:36 AM) RP: bluelightning: remove the need to bbappend, have
> > > people set mode config options
> > > (9:47:51 AM) bluelightning: and PACKAGECONFIG to enable deps on
> > > things
> > > outside OE-Core as well presumably
> > > (9:48:01 AM) bluelightning: (as discussed on the ml a few weeks
> > > ago)
> > > (9:48:06 AM) fray: yup
> > 
> > Well found. There is clearly more context behind that even back
> > then.
> > 
> > > I spent last couple hours digging through my archives of
> > > openembedded-core and 
> > > openembedded-devel lists around that time (Spring 2013), but
> > > besides
> > > general move to enable PACKAGECONFIG in recipes, I didn't see
> > > anything specific about crossing layer boundaries by
> > > PACKAGECONFIG
> > > dependencies, unfortunately. And it was a wild time - all the
> > > energy,
> > > extra activity, conflicts, flamewars - that definitely brought up
> > > some memories re-reading those discussions again... :)
> > 
> > :)
> > 
> > I'm sure this has been discussed, I just don't remember where/when
> > unfortunately.
> > 
> > I do believe the conclusion is right though and I believe there is
> > enough general acceptance we can document it as such. If anyone
> > objects, the TSC can discuss it but I'm not seeing that being
> > requested
> > unless there is more context to this discussion than I'm seeing.
> 
> Richard,
> 
> So, the policy issue is all sorted out now...
> 
> But how one would use this change in a multi-machine distro, when
> some 
> machines have graphics and want qt5+gl dependencies, while other
> machines 
> have no graphics and cannot build qt5+gl. Is there a way to keep
> this 
> package generic w/o making it machine-specific
> PACKAGE_ARCH=MACHINE_ARCH?

The distro could setup the package feeds so there was a package feed
with gl and a package feed without gl?

The tune files ultimately determine the default PACKAGE_ARCH but there
is nothing stopping the distro from changing that to gl and non-gl
variants...

Cheers,

Richard