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

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

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?

Cheers,

Richard