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

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

On Mon, 2011-11-14 at 21:55 +0100, Koen Kooi wrote:
> Op 14 nov. 2011, om 21:39 heeft Richard Purdie het volgende geschreven:
> > On Mon, 2011-11-14 at 20:17 +0100, Koen Kooi wrote:
> >> I think splitting distccmon-gnome into a seperate recipe is a better idea.
> > 
> > I think that makes sense in some cases but I'd hate for it to become the
> > default approach for issues like this as the duplication of code,
> > parsing and build time etc. grate on me. Do we really need separate
> > recipes?
> 
> I think for this case, yes. And I'll happily trade needing extra
> buildtime for not needing USEFLAGS.
> 
The proposals for alternative recipes for the different combinations got
voted down and PACKAGECONFIG was the preferred solution. I can't say I
personally like everything about the outcome. I do however understand
why we've ended up in that position and don't intend to undermine the
usefulness of it.

> > I'll probably take this patch as it improves the situation IMO (and
> is
> > easy to change the configuration from a distro config if anyone does
> > have an issue with it being disabled).
> 
> This patch changes the default behaviour in a way that distros need to
> update their configs in order to keep the status quo. I know I use
> distccmon-gnome on my boards, but will I remember 2 months from now
> that this patch went in? I asked this before in a different context,
> but I'll ask again: do you expect distro maintainers to vet each and
> every commit that goes into OE-core to find out when default got
> (silently) changed?
> 
> USEFLAGS should be a last resort when having seperate recipes doesn't
> work out, not a default cure. 

The discussion and decision went against this, rightly or wrongly
PACKAGECONFIG is here and we should start to use it. In some cases it
will help you a lot, in others it will cause you a bit more work. Such
is life.

However I do agree the defaults should be backwards compatible so I'm
going to ask Paul to resubmit with a default value that matches the
original recipe, probably something like:

PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \
                   ${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}

although we could/should probably have some kind of "HAVEGTK" macro type
variable defined to help avoid some of this ugliness.

Cheers,

Richard