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

[Phil Blundell <philb@gnu.org>]

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).

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).

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.

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.

p.