On 10/03/14 10:48, Joshua Kinard wrote: > On 03/10/2014 2:59 AM, Alexandre Rostovtsev wrote: >> On Mon, 2014-03-10 at 01:45 -0400, Alexandre Rostovtsev wrote: >>> On Sun, 2014-03-09 at 23:22 -0400, Joshua Kinard wrote: >>>> On 03/08/2014 9:55 PM, Alexandre Rostovtsev wrote: >>>>> On Sat, 2014-03-08 at 21:23 -0500, Joshua Kinard wrote: >>>>>> So I want to try and play around with a particular network domination >>>>>> tool >>>>>> on my home network, Omphalos. However, its current configure script has >>>>>> a >>>>>> hard dependency on bluetooth.h, part of the net-wireless/bluez package. >>>>>> >>>>>> Currently, net-wireless/bluez has a harddep on virtual/udev, which works >>>>>> great if you use either udev or eudev. I'm using busybox's mdev >>>>>> instead, so >>>>>> the logic of the bluez ebuild needs some changes: >>>>> [...] >>>>>> Thoughts on this? >>>>> Does mdev have any API which is equivalent to libudev's hwdb? See >>>>> http://www.freedesktop.org/software/systemd/libudev/libudev-udev-hwdb.html >>>>> >>>>> If yes, then optimal solution would be to patch bluez to allow using >>>>> mdev's hwdb support, and get the patch upstreamed :) >>>> It's actually not a matter of the hwdb support, it's just the fact that >>>> bluez currently has a harddep on a specific device manager, either udev or >>>> eudev. >>> Bluez does not require an abstract device manager. It requires the >>> libudev library. Or rather, it requires some kind of library which >>> provides the following API: >>> >>> 1. querying hwdb (given a kernel modalias for a device, retrieve >>> corresponding oui, vendor, and model data); and >>> 2. querying the device tree (manually traversing /sys is of course >>> possible, but not very easy to do correctly, so bluez developers are >>> relying on libudev). >> And by "requires", I mean that without libudev, a variety of bluetooth >> devices and adapters will simply fail to work. >> >> So if mdev does not have some equivalent of libudev, a reasonable >> solution would probably be the following: >> >> @@ -14,19 +14,19 @@ >> LICENSE="GPL-2+ LGPL-2.1+" >> SLOT="0/3" >> KEYWORDS="~amd64 ~arm ~hppa ~ppc ~ppc64 ~x86" >> -IUSE="cups debug +obex readline selinux systemd test" >> +IUSE="cups debug +obex readline selinux systemd test +udev" >> REQUIRED_USE="test? ( ${PYTHON_REQUIRED_USE} )" >> >> RDEPEND=" >> >=dev-libs/glib-2.28:2 >> >=sys-apps/dbus-1.6:= >> >=sys-apps/hwids-20121202.2 >> - >=virtual/udev-171 >> cups? ( net-print/cups:= ) >> obex? ( dev-libs/libical ) >> readline? ( sys-libs/readline:= ) >> selinux? ( sec-policy/selinux-bluetooth ) >> systemd? ( sys-apps/systemd ) >> + udev? ( >=virtual/udev-171 ) >> " >> DEPEND="${RDEPEND} >> virtual/pkgconfig >> @@ -46,6 +46,11 @@ >> pkg_setup() { >> enewgroup plugdev >> use test && python-any-r1_pkg_setup >> + >> + if ! use udev; then >> + ewarn "You are installing ${P} with USE=-udev. This means >> various bluetooth" >> + ewarn "devices and adapters from Apple, Dell, Logitech etc. >> will fail to work." >> + fi >> } >> >> src_prepare() { >> @@ -92,13 +97,13 @@ >> $(use_enable test) \ >> --enable-tools \ >> --enable-monitor \ >> - --enable-udev \ >> + $(use_enable udev) \ >> $(use_enable cups) \ >> $(use_enable obex) \ >> --enable-client \ >> $(use_enable systemd) \ >> $(systemd_with_unitdir) \ >> - --enable-sixaxis >> + $(use_enable udev sixaxis) >> } >> >> src_install() { >> @@ -134,7 +139,7 @@ >> pkg_postinst() { >> readme.gentoo_print_elog >> >> - udev_reload >> + use udev && udev_reload >> >> has_version net-dialup/ppp || elog "To use dial up networking you must >> install net-dialup/ppp." >> > Hey, this sounds like it'll work in my case :) > > I don't use bluetooth, nor udev, so the issues surrounding making udev > optional in bluez or not isn't really my concern. Making udev optional was > the easier solution than trying to figure out how to cut out the lib/ folder > from bluez and wrapping it in a separate libbluetooth package. Thought I'd > just suggest the solution to the list for input. >
You know, you can have udev installed (to have libudev installed) but still run something else, like mdev It would likely still work for this case even if udevd daemon isn't running And yes, I realize it's not perfect for some embedded systems
