[OE-core] [PATCH 2/2] udev: Don't introduce pci dependencies without pci being featured

[Jens Rehsack]

> Am 08.10.2015 um 19:22 schrieb Martin Jansa <martin.jansa at gmail.com>:
> 
> On Thu, Oct 08, 2015 at 05:26:11PM +0200, Jens Rehsack wrote:
>> Fixes that udev always requires PCI, idenpendently from machine or distro features.
>> 
>> Signed-off-by: Jens Rehsack <sno at netbsd.org>
>> ---
>> meta/recipes-core/udev/udev.inc | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>> 
>> diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
>> index c378ae3..573ecca 100644
>> --- a/meta/recipes-core/udev/udev.inc
>> +++ b/meta/recipes-core/udev/udev.inc
>> @@ -12,7 +12,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
>> 
>> LDFLAGS += "-lrt"
>> 
>> -DEPENDS = "glib-2.0 libusb usbutils pciutils glib-2.0-native gperf-native libxslt-native util-linux"
>> +DEPENDS = "glib-2.0 glib-2.0-native gperf-native libxslt-native util-linux"
>> +DEPENDS += " ${@base_contains('MACHINE_FEATURES', 'usbhost', 'libusb usbutils', '', d)}"
>> +DEPENDS += " ${@base_contains('MACHINE_FEATURES', 'pci', 'pciutils', '', d)}"
> 
> NAK
> 
> udev isn't (and shouldn't be) MACHINE_ARCH, so it cannot use
> MACHINE_FEATURES variable.

Why shouldn't be?

We have 2 machines, both iMX6 based, one with Multimedia and one without.
For the -lite one, we wouldn't want provide rules for dealing with hdmi,
audio, ...

The other ARM machines we have which are complete different platforms
(iMX6 vs. Kirkwood) are distinguished by armv5 vs. armv7 - but what
happens when another platform joins the farm which is ARMv7 but no i.MX?

> Please change them to PACKAGECONFIG options and distro can decide to
> disable them for all MACHINEs (or at least for whole set of MACHINEs
> sharing the same TUNE_PKGARCH)

This should be done along with some reasonable documentation how to
tune that - can you give me (depending on my question above) a hint where
to add such a notice for platform integrators?

Cheers
-- 
Jens Rehsack - rehsack at gmail.com