Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

[Michał Górny]

Dnia 2014-03-10, o godz. 06:57:22
Joshua Kinard <kumba@g.o> napisał(a):

> 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:
>
> [...]
>
> 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'm sorry but I don't get what you are complaining about.

Bluez -- that is the package that aims to bring bluetooth support --
requires udev to support most of bluetooth hardware, and properly
depends on it. You are complaining about that because it collides with
your fancy device manager that doesn't have any API that could bring
hardware support to bluez.

So now, do you request that we should provide bluez *without* bluetooth
support? Wouldn't the correct solution be to, say, make bluetooth
support in your package optional if you don't need it?

-- 
Best regards,
Michał Górny