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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
