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

["Denys Dmytriyenko" <denis@denix.org>]

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?

-- 
Denys