[OE-core] [PATCH 3/4] distcc: make distccmon-gnome optional and default to off

[Koen Kooi]

Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven:

> On Tue, 2011-11-15 at 13:15 +0100, Koen Kooi wrote:
>> Op 15 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven:
>> 
>>> On Tuesday 15 November 2011 08:58:00 Koen Kooi wrote:
>>>> Let's move this to the TSC and see if we can get this crap removed. There is
>>>> already an existing ruling that USEFLAGS should be a last resort. I'm tired
>>>> of yocto-marketing feel good patches making life harder for people actually
>>>> using oe-core and its output.
>>> 
>>> Marketing has nothing to do with it. All I really want is to fix the problem 
>>> that the build blows up if you try to build any image for any of the qemu* 
>>> machines with x11 removed from DISTRO_FEATURES.
>> 
>> Isn't a better question "Why are all images for qemu machines forcing distcc to get built?"?
> 
> Both questions are valid:
> 
> a) If I build distcc and I have x11 disabled, it shouldn't break.
> 
> b) Should qemu include distcc?
> 
> Traditionally, qemu-config does pull it in. Why? The qemu scripts allow
> pass through of compilation to the build system instead of doing it
> under emulation for a significant speed up in compile time. It was
> originally felt that it should therefore maximally autoconfigure that
> stuff transparently to the user.
> 
> If we don't think that is useful we can drop it. That is a separate
> discussion to a) which seems to be the contentious problem and solving
> b) is just hiding from the issue.
> 
>> Or just make a seperate recipe for distccmon-gnome, that would avoid
>> the need of any USEFLAGS. Should be just a matter of require distcc_
>> $PV.bb ; EXTRA_OEOCONF = foo
> 
> and the rest (resolving the various packaging conflicts so that
> distcc-gnome only packages the gnome pieces and removes everything
> else).
> 
> To put this quite simply, I think there is no good reason we shouldn't
> use the mechanism we've selected to handle this kind of problem. We
> should have defaults the reflect backwards compatibility. Other than
> that where is the problem other than a general objection to
> PACKAGECONFIG?

It forces a choice when there is a solution where things can coexist.

regards,

Koen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111115/999c06e8/attachment-0002.sig>