On 03/10/2014 5:55 AM, Samuli Suominen wrote: > > 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
Except the tool I wanted to test out, Omphalos, doesn't need _anything_ from udev or libudev. It wants bluetooth.h and probably whatever .so/.a files are tied to that specific header: """ A tool for network enumeration, protection, observation and domination. Omphalos makes use of passive and active portscanning, DNS/DHCP/Zeroconf server interrogation, portknock detection, covert channel detection and establishment, ARP scanning, automatic WEP cracking, man-in-the-middling, and a whole host of other tricks. GPS integration? Oh yes. Coordination across multiple interfaces? Of course. Use of Linux's MMAP_RX_SOCKET and MMAP_TX_SOCKET? Wouldn't have it any other way. Userspace networking is made visible to the host via a TUN/TAP device. While designed as an offensive tool, omphalos has proven useful for network debugging and troubleshooting, as well as experimentation. Omphalos is not a "point-and-click" tool so much as "pull the pin" or perhaps "spray the area". Default behavior is to redirect and seize all traffic, attack weak cryptosystems, archive authentication materials, and learn everything that can be learned. """ It's bluez that wants to invite the entire udev/systemd party in, because of the virtual/udev harddep. So, I modded a local copy of bluez to not need virtual/udev initially so I could get past Omphalos' bluetooth build requirement. But I got stopped by the need for wireless, which is not in the kernel running on my main Linux machine (Ethernet II only, weee). I thought I'd at least make the udev hacks to my bluez ebuild a little cleaner and submit them for inclusion in the tree, cause generally, there's nothing wrong about making udev optional where it's supported to be optional (as evidenced by bluez's --enable-udev switch to configure). The other option is to split the files in bluez's lib/ directory off into their own libbluetooth package. Maybe there's other packages in the tree that just need bluetooth.h and not the entire kitten kaboodle that is bluez. Then bluez can keep its udev harddep and have bluez/libbluetooth block each other and call it a day. Or we can just do nothing. I'll just keep my modded bluez ebuild around for testing things locally. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
