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