Op 3 jun 2011, om 10:24 heeft Richard Purdie het volgende geschreven: > On Fri, 2011-06-03 at 08:37 +0200, Koen Kooi wrote: >> Op 3 jun 2011, om 03:06 heeft Khem Raj het volgende geschreven: >> >>> On Thursday, June 02, 2011 09:37:41 AM Richard Purdie wrote: >>>> On Wed, 2011-06-01 at 20:40 +0000, Otavio Salvador wrote: >>>>> On Wed, Jun 1, 2011 at 20:37, Phil Blundell <p...@pbcl.net> wrote: >>>>>> On Wed, 2011-06-01 at 20:09 +0000, Otavio Salvador wrote: >>>>>>> -# CONFIG_MDEV is not set >>>>>>> +CONFIG_MDEV=y >>>>>> >>>>>> Per previous discussion, I am still uneasy about this change. I think >>>>>> we really need some sort of coherent policy for what exactly the >>>>>> default busybox configuration in oe-core is meant to be doing, and >>>>>> then (if necessary) a set of patches to make it match the policy. >>>>>> Just flipping random features on and off does not seem like a good way >>>>>> to proceed. >>>>> >>>>> OE-core has support to mdev as device handling mechanism as such this >>>>> ought to be enabled by default IMO. >>>>> >>>>> Personally it doesn't matter since I have already overriden it in my >>>>> internal layer. >>>> >>>> I'm afraid I'm with Phil on this. I don't like the idea of enabling >>>> something we don't actually use. This really needs to become some kind >>>> of configure option which would at the same time disable/replace udev so >>>> the patch in its currently form isn't acceptable. >>>> >>> >>> mdev or udev are image features so probably should be controlled by >>> IMAGE_FEATURES or some such >> >> You can't put IMAGE_FEATURES in the equivalent of EXTRA_OECONF since >> the packages in the feeds don't magically change when being installed >> in a different image. > > Right, it would have to be a DISTRO_FEATURE for that reason...
Right, but you can build mdev and choose not to use it, which is what .dev currently does. So while the distro could in theory set a DISTRO_FEATURE, we shouldn't make other decisions based on that, like deciding that if mdev is in DISTRO_FEATURES every image will use it. regards, Koen _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
