| 1 |
On 10/03/14 10:48, Joshua Kinard wrote: |
| 2 |
> On 03/10/2014 2:59 AM, Alexandre Rostovtsev wrote: |
| 3 |
>> On Mon, 2014-03-10 at 01:45 -0400, Alexandre Rostovtsev wrote: |
| 4 |
>>> On Sun, 2014-03-09 at 23:22 -0400, Joshua Kinard wrote: |
| 5 |
>>>> On 03/08/2014 9:55 PM, Alexandre Rostovtsev wrote: |
| 6 |
>>>>> On Sat, 2014-03-08 at 21:23 -0500, Joshua Kinard wrote: |
| 7 |
>>>>>> So I want to try and play around with a particular network domination tool |
| 8 |
>>>>>> on my home network, Omphalos. However, its current configure script has a |
| 9 |
>>>>>> hard dependency on bluetooth.h, part of the net-wireless/bluez package. |
| 10 |
>>>>>> |
| 11 |
>>>>>> Currently, net-wireless/bluez has a harddep on virtual/udev, which works |
| 12 |
>>>>>> great if you use either udev or eudev. I'm using busybox's mdev instead, so |
| 13 |
>>>>>> the logic of the bluez ebuild needs some changes: |
| 14 |
>>>>> [...] |
| 15 |
>>>>>> Thoughts on this? |
| 16 |
>>>>> Does mdev have any API which is equivalent to libudev's hwdb? See |
| 17 |
>>>>> http://www.freedesktop.org/software/systemd/libudev/libudev-udev-hwdb.html |
| 18 |
>>>>> |
| 19 |
>>>>> If yes, then optimal solution would be to patch bluez to allow using |
| 20 |
>>>>> mdev's hwdb support, and get the patch upstreamed :) |
| 21 |
>>>> It's actually not a matter of the hwdb support, it's just the fact that |
| 22 |
>>>> bluez currently has a harddep on a specific device manager, either udev or |
| 23 |
>>>> eudev. |
| 24 |
>>> Bluez does not require an abstract device manager. It requires the |
| 25 |
>>> libudev library. Or rather, it requires some kind of library which |
| 26 |
>>> provides the following API: |
| 27 |
>>> |
| 28 |
>>> 1. querying hwdb (given a kernel modalias for a device, retrieve |
| 29 |
>>> corresponding oui, vendor, and model data); and |
| 30 |
>>> 2. querying the device tree (manually traversing /sys is of course |
| 31 |
>>> possible, but not very easy to do correctly, so bluez developers are |
| 32 |
>>> relying on libudev). |
| 33 |
>> And by "requires", I mean that without libudev, a variety of bluetooth |
| 34 |
>> devices and adapters will simply fail to work. |
| 35 |
>> |
| 36 |
>> So if mdev does not have some equivalent of libudev, a reasonable |
| 37 |
>> solution would probably be the following: |
| 38 |
>> |
| 39 |
>> @@ -14,19 +14,19 @@ |
| 40 |
>> LICENSE="GPL-2+ LGPL-2.1+" |
| 41 |
>> SLOT="0/3" |
| 42 |
>> KEYWORDS="~amd64 ~arm ~hppa ~ppc ~ppc64 ~x86" |
| 43 |
>> -IUSE="cups debug +obex readline selinux systemd test" |
| 44 |
>> +IUSE="cups debug +obex readline selinux systemd test +udev" |
| 45 |
>> REQUIRED_USE="test? ( ${PYTHON_REQUIRED_USE} )" |
| 46 |
>> |
| 47 |
>> RDEPEND=" |
| 48 |
>> >=dev-libs/glib-2.28:2 |
| 49 |
>> >=sys-apps/dbus-1.6:= |
| 50 |
>> >=sys-apps/hwids-20121202.2 |
| 51 |
>> - >=virtual/udev-171 |
| 52 |
>> cups? ( net-print/cups:= ) |
| 53 |
>> obex? ( dev-libs/libical ) |
| 54 |
>> readline? ( sys-libs/readline:= ) |
| 55 |
>> selinux? ( sec-policy/selinux-bluetooth ) |
| 56 |
>> systemd? ( sys-apps/systemd ) |
| 57 |
>> + udev? ( >=virtual/udev-171 ) |
| 58 |
>> " |
| 59 |
>> DEPEND="${RDEPEND} |
| 60 |
>> virtual/pkgconfig |
| 61 |
>> @@ -46,6 +46,11 @@ |
| 62 |
>> pkg_setup() { |
| 63 |
>> enewgroup plugdev |
| 64 |
>> use test && python-any-r1_pkg_setup |
| 65 |
>> + |
| 66 |
>> + if ! use udev; then |
| 67 |
>> + ewarn "You are installing ${P} with USE=-udev. This means various bluetooth" |
| 68 |
>> + ewarn "devices and adapters from Apple, Dell, Logitech etc. will fail to work." |
| 69 |
>> + fi |
| 70 |
>> } |
| 71 |
>> |
| 72 |
>> src_prepare() { |
| 73 |
>> @@ -92,13 +97,13 @@ |
| 74 |
>> $(use_enable test) \ |
| 75 |
>> --enable-tools \ |
| 76 |
>> --enable-monitor \ |
| 77 |
>> - --enable-udev \ |
| 78 |
>> + $(use_enable udev) \ |
| 79 |
>> $(use_enable cups) \ |
| 80 |
>> $(use_enable obex) \ |
| 81 |
>> --enable-client \ |
| 82 |
>> $(use_enable systemd) \ |
| 83 |
>> $(systemd_with_unitdir) \ |
| 84 |
>> - --enable-sixaxis |
| 85 |
>> + $(use_enable udev sixaxis) |
| 86 |
>> } |
| 87 |
>> |
| 88 |
>> src_install() { |
| 89 |
>> @@ -134,7 +139,7 @@ |
| 90 |
>> pkg_postinst() { |
| 91 |
>> readme.gentoo_print_elog |
| 92 |
>> |
| 93 |
>> - udev_reload |
| 94 |
>> + use udev && udev_reload |
| 95 |
>> |
| 96 |
>> has_version net-dialup/ppp || elog "To use dial up networking you must install net-dialup/ppp." |
| 97 |
>> |
| 98 |
> Hey, this sounds like it'll work in my case :) |
| 99 |
> |
| 100 |
> I don't use bluetooth, nor udev, so the issues surrounding making udev |
| 101 |
> optional in bluez or not isn't really my concern. Making udev optional was |
| 102 |
> the easier solution than trying to figure out how to cut out the lib/ folder |
| 103 |
> from bluez and wrapping it in a separate libbluetooth package. Thought I'd |
| 104 |
> just suggest the solution to the list for input. |
| 105 |
> |
| 106 |
|
| 107 |
You know, you can have udev installed (to have libudev installed) but |
| 108 |
still run something else, like mdev |
| 109 |
It would likely still work for this case even if udevd daemon isn't running |
| 110 |
|
| 111 |
And yes, I realize it's not perfect for some embedded systems |
Archives