Re: [PATCH] task-base: conditional wifi and bluetooth tasks in PACKAGES

[Tom Rini <tom_rini@mentor.com>]

On 02/09/2011 08:22 AM, Phil Blundell wrote:
> On Wed, 2011-02-09 at 08:01 -0700, Tom Rini wrote:
>> So... wouldn't making the patch be DISTRO_FEATURES rather than
>> MACHINE_FEATURES be what people want?
>
> I think that's still not quite right.  As far as I can tell there are
> three interesting scenarios that need to be distinguished:
>
> 1. DISTRO doesn't want bluetooth at all: bluez shouldn't be built,
> nothing should depend on it, and bluetooth should be disabled in all
> packages where it's an option.  If nothing is using bluez then clearly
> it isn't going to be wanted in the bootstrap images.
>
> 2. DISTRO does want bluetooth as an option in the feeds but it isn't
> needed for bootstrapping (on distros where that's a meaningful concept).
> Bluez should be built, packages where it's an option should depend on
> it, but task-base/task-bootstrap should not make any special effort to
> haul bluez into the installation images.
>
> 3. DISTRO wants bluetooth and it is required for bootstrapping.  In this
> case, evidently something in task-base/task-bootstrap needs to RDEPEND
> on it in order to make sure it's available at install time.
>
> I think case (1) corresponds to DISTRO_FEATURES not including bluetooth.
> Case (3) corresponds to DISTRO_FEATURES having bluetooth and the MACHINE
> declaring that it is bluetooth-capable in some way (either by mentioning
> it directly in MACHINE_FEATURES or by mentioning a bus like pci or cf
> which could accept a bluetooth card).

Right, and same for "wifi" (which is a much smaller set of stuff that 
gets pulled in).

> The difficulty seems to be that, for case (2), there is currently no way
> for a DISTRO to say that it isn't interested in bluetooth for bootstrap
> purposes even though the hardware might be capable of it.  That might be
> a legitimate point of view if all the hardware that it runs on also
> supports an easier bootstrap method (e.g. wifi).

I think in the cases where it's being pulled into the image, doing 
$distro-bootstrap-image.bb which just adds the logic that says "remove 
... for $machine" and spits out the N different bootstrap possible 
images is fine.  But the problem, if I read it right is:

Lots of things are being built and then task-base-{bluetooth,wifi} 
exist, but aren't installed.

> If you change the patch to just look at DISTRO_FEATURES then it will
> essentially be a no-op since the distros which are having this problem
> must already be enabling bluetooth in DISTRO_FEATURES.

I warned you I have my stupid hat on, but jlime-2010.1.conf doesn't list 
bluetooth or wifi.

> All that said, though, I think there is a fairly strong case for just
> saying that each distro should provide its own task-bootstrap equivalent
> (if it cares about bootstrapping).  It seems a bit silly to try to have
> a single one-size-fits-all recipe with a zillion little switches that
> make it behave differently in a multitude of ways.

I don't know.  Switching hats, we've never used task-base/etc since it's 
always pulled in more stuff than we cared for and seemed like a PITA to 
take things out.  But it's also long been a wishlist item to give it 
another go.  But it's a good and honest question, does task-base really 
work today, as the various distros wish that it would, for anyone other 
than Angstrom?  If not, that'd be a pretty good case for abstracting 
things a little and saying if you want to use images X/Y/Z, $distro 
needs to provide $something that's installed in the images and it must 
do ....

-- 
Tom Rini
Mentor Graphics Corporation