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

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

[Joshua Kinard]

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:

--- bluez-5.15.ebuild	2014-03-08 21:13:24.049329018 -0500
+++ bluez-5.15-r1.ebuild	2014-03-08 21:17:28.029686862 -0500
@@ -16,3 +16,3 @@ 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} )"
@@ -23,3 +23,4 @@ RDEPEND="
 	>=sys-apps/hwids-20121202.2
-	>=virtual/udev-171
+	udev? ( >=virtual/udev-171 )
+	!udev? ( virtual/dev-manager )
 	cups? ( net-print/cups:= )
@@ -94,3 +95,3 @@ src_configure() {
 		--enable-monitor \
-		--enable-udev \
+		$(use_enable udev) \
 		$(use_enable cups) \
@@ -136,3 +137,5 @@ pkg_postinst() {

-	udev_reload
+	if use udev ; then
+		udev_reload
+	fi

Thoughts on this?

The other option is to split the libbluetooth bits out from bluez and put
them into their own package.  This would be equivalent to Debian's
libbluetooth-dev it looks.  Anyone know of any other use cases where a
separate libbluetooth package would be useful?

Omphalos:
http://nick-black.com/dankwiki/index.php/Omphalos

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Alexandre Rostovtsev]

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 :)

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

[Samuli Suominen]

On 09/03/14 04:55, 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 :)
>
>

No, the hwdb.bin is specific to >=udev-180 (can't remember exact
version, but it was around after 180)

Did you mean to imply the bluez package is severely crippled without the
database?
If so, then why not do what Joshua asked but package.use.force the
USE="udev" enabled,
with an explanation in the comment, and let people unforce it if they
really want?

- Samuli

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

[hasufell]

Samuli Suominen:
> 
> On 09/03/14 04:55, 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 :)
>>
>>
> 
> but package.use.force the
> USE="udev" enabled,

force/mask doesn't always improve user experience and should not be used
deliberately, IMO

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

[Joshua Kinard]

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.  By adding the USE conditionals, we can depend on virtual/udev if USE
contains 'udev' (and pass --enable-udev to configure), else, we depend on
virtual/dev-manager (and --disable-udev) for any *other* device manager out
there, which covers mdev in my specific case.

Granted, I got hung up trying to build Omphalos anyways, as my current
running kernel lacks wifi support, and that doesn't appear to be optional.
Have to hack around that or reboot w/ wifi just to build it.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Alexandre Rostovtsev]

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).

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

[Alexandre Rostovtsev]

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."
 

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

[Joshua Kinard]

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.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Samuli Suominen]

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

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

[Joshua Kinard]

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
kumba@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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 6114 bytes --]

Dnia 2014-03-10, o godz. 06:57:22
Joshua Kinard <kumba@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

Picking a random mail in the thread.

Making udev dependency always on is a deliberate choice here, as noted
by Alexandre, the library will be most likely useless without it and we
simply don't want users to get confused about what might not work in the
stack when bluetooth isn't particularly easy to get going already.

Anyway if there is a real point in having more possibilities to shoot
ourselves in the foot, please file a bug report. This is the usual way
to get this sorted out.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Joshua Kinard]

On 03/10/2014 1:27 PM, Michał Górny wrote:
[snip]
> 
> 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?


That's not what I am saying.  I proposed a patch to make udev optional in
bluez because it apparently allows for this support to be optional:

> bluez-5.15$ ./configure --help
> `configure' configures bluez 5.15 to adapt to many kinds of systems.
> 
> Usage: ./configure [OPTION]... [VAR=VALUE]...
[snip]
> Optional Features:
>   --disable-option-checking  ignore unrecognized --enable/--with options
>   --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
>   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
[snip]
>   --disable-udev          disable udev device support
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't know what the side-effects are of disabling udev support are.  I
simply saw that switch in the configure script's --help output, and so I
thought I'd modify my local ebuild copy to depend on the 'udev' USE flag to
make udev optional so I could try and get omphalos' configure script to
complete successfully.  Which it didn't for reasons I've already stated.

I have to do further experiments and probably get a hold of omphalos'
upstream team to better understand why they require bluetooth support in the
current codebase.  Maybe it can be made optional -- I don't know just yet.

Anyways, you say bluez requires udev, but the bluez configure script
suggests otherwise.   I don't know (or care, really) the reasons why.
That's a question for the bluez developers I guess.  Alex's patch looks to
be better than my proposed solution, so if there is desire, that's probably
what should be used.  However, if our bluetooth experts think that allowing
udev to be optional does more harm than good, then I guess it needs to
remain a harddep.

In that case, the better solution probably is either to make bluetooth
optional in omphalos or create a libbluetooth package that provides the
header/libs that'd satisfy the build condition.  We've done it before, but
I'll have to look into it at another time.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

Gilles Dartiguelongue wrote:
> Making udev dependency always on is a deliberate choice here

I thought Gentoo was about users having choice? Sad face.


> we simply don't want users to get confused

That's not helpful, when the premise is to deliver choice.


I hope someone does apply the patch.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
> Gilles Dartiguelongue wrote:
> > Making udev dependency always on is a deliberate choice here
> 
> I thought Gentoo was about users having choice? Sad face.

Gentoo is usually about the maintainer's choice ;)

So in the end it's up to Pacho:
https://bugs.gentoo.org/show_bug.cgi?id=504324

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rich Freeman]

On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:
> On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
>> Gilles Dartiguelongue wrote:
>> > Making udev dependency always on is a deliberate choice here
>>
>> I thought Gentoo was about users having choice? Sad face.
>
> Gentoo is usually about the maintainer's choice ;)
>
> So in the end it's up to Pacho:
> https://bugs.gentoo.org/show_bug.cgi?id=504324

Honestly, of all the suggestions in this thread having the use-enable
config setting and just outputting a warning when udev isn't enabled
seems like the best solution.

Sure, it is up to the maintainer, but in general we should try to
support config options like this.  If we only wanted packages that
"just work" with no risk of breakage we'd be running debian.  USE
flags are a big point of what we're about.

Anybody setting USE=-udev system-wide needs to appreciate that stuff
like usb/bluetooth/etc which is runtime auto-configuring is fairly
likely to not work.  The profile defaults already seem reasonable, so
it shouldn't be necessary to force it off for a typical user - base
users will tend to get udev only if they install something like bluez,
which is what 95% of users will want.  For those who want to override
the defaults we should give them the option to shoot themselves in
both feet and the head as well if they are eager.

Users who really want the "Debian-like" experience should just avoid
setting use flags at all and pick a profile.  USE defaults and
profiles really eliminate the "need" to tweak that stuff, and emerge
can auto-set package settings if required for a dependency.

Rich

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

[Joshua Kinard]

On 03/12/2014 4:21 PM, Rich Freeman wrote:
> On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev
> <tetromino@gentoo.org> wrote:
>> On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
>>> Gilles Dartiguelongue wrote:
>>>> Making udev dependency always on is a deliberate choice here
>>>
>>> I thought Gentoo was about users having choice? Sad face.
>>
>> Gentoo is usually about the maintainer's choice ;)
>>
>> So in the end it's up to Pacho:
>> https://bugs.gentoo.org/show_bug.cgi?id=504324
> 
> Honestly, of all the suggestions in this thread having the use-enable
> config setting and just outputting a warning when udev isn't enabled
> seems like the best solution.

Agreed, Alex's patch properly addresses the issue I originally raised.  My
initial thinking was to replace virtual/udev with the more generic
virtual/dev-manager, because I didn't dig deep into understanding why
virtual/udev was actually needed (I don't use bluetooth on a daily basis).


-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/10/2014 07:29 PM, Gilles Dartiguelongue wrote:
> Picking a random mail in the thread.
> 
> Making udev dependency always on is a deliberate choice here, as noted
> by Alexandre, the library will be most likely useless without it and we
> simply don't want users to get confused about what might not work in the
> stack when bluetooth isn't particularly easy to get going already.
> 
> Anyway if there is a real point in having more possibilities to shoot
> ourselves in the foot, please file a bug report. This is the usual way
> to get this sorted out.
> 
Picking the most appropriate mail in the thread to ++

++

Honestly I'd rather see this split up into libbluetooth and bluez than
make it possible to build a nearly entirely crippled bluez with no udev
support.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTPHKjAAoJEKXdFCfdEflKhX8P/1pwbM98aWmG/32a/U8cTit6
Zxjffk9XeXkFSGH9JJYNTPc6plK9fWtRYS4bxUA7tj0xYjN3N/xrAo42g5qZbVCc
1/TiN9iu+gLQmBlWi5JI1V0r/bdyK5UBYyl5PnW3oy+PSGoFMGEW+osql4jBzhVS
QjHgxHEuG6dWJSlqtKtOHai7GPm4YDnAiry4QY5mMWMS6Y5Fy56ycp6pc20rN0nV
gywiVJnRBEaHitJBwBICTwwXHK1dhcRH5WOJVTkyJ9ZFT1ZAERboPoXVlzYbyXxv
JBGjaC5Llk2KtfPdtJLdlO7DZtTTZOQc2A6mwnsFDthD47UY1nlv4TyYY/MYTp77
59jel7GfboU3cP9ts0Gx/qwG4AsDKqTFHT5pq589usYGz4l/imvg32UdcoRJpJJf
ZTYmtM30BiOV8lI3FwcztLjefFf6w0NiLqkVG8erLumo8by1lWvhHsRaXX/J98br
XOSLEC26NU9fjH6PSMncgY6676ibFPoBWLzb/NUjs88MqSMWLzJY2m13TitVtXhQ
K5OWjg8jfjXmF1fQXOlp2u8kGbIpG751ZznjGwwj3RaXeZeZcH2h3hMo9nAB1tqy
YWv57ca+HcctSLma11ynDdyXpdxWhupLJH1RDqoc+6GUDdw8eojiIoLfgkmooQrQ
w6TV7fYSgELApJ372/74
=iAla
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Wed, Apr 2, 2014 at 4:27 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> Honestly I'd rather see this split up into libbluetooth and bluez than
> make it possible to build a nearly entirely crippled bluez with no udev
> support.

I think the right approach really depends on usefulness.  Splitting
packages has its own set of issues.  If it really made sense in the
general case to install one without the other splitting would make
managing dependencies a lot cleaner.  However, if this is really so
that 10 Gentoo users can avoid having udev installed just give them a
flag and a warning and let them keep the pieces if they break their
box.

I mean, who is going to set USE=-udev globally and not expect that
something could go wrong?  Anybody who is going to set up busybox mdev
isn't going to try to make that switch over their lunch break on a
production box.

Rich

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

[Joshua Kinard]

On 04/02/2014 16:47, Rich Freeman wrote:
> On Wed, Apr 2, 2014 at 4:27 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>> Honestly I'd rather see this split up into libbluetooth and bluez than
>> make it possible to build a nearly entirely crippled bluez with no udev
>> support.
> 
> I think the right approach really depends on usefulness.  Splitting
> packages has its own set of issues.  If it really made sense in the
> general case to install one without the other splitting would make
> managing dependencies a lot cleaner.  However, if this is really so
> that 10 Gentoo users can avoid having udev installed just give them a
> flag and a warning and let them keep the pieces if they break their
> box.

I guess this is more of a question to be asked to the bluez developers why
they even allow the bluez configure script to make udev optional.  If they
put that in there, there must be a good reason for it.  So in one way, we're
simply exposing additional functionality already in the package.


> I mean, who is going to set USE=-udev globally and not expect that
> something could go wrong?  Anybody who is going to set up busybox mdev
> isn't going to try to make that switch over their lunch break on a
> production box.

Actually, it took me about an hour to migrate off of udev.  Most of the
little problems left over were packages I forgot to rebuild w/ USE="-udev".
 I've either done that, or set package-specific USE flags to cut udev out
when needed.

Setup a VM and try it.  See what life is like on the other side!

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Peter Stuge]

Joshua Kinard wrote:
> I guess this is more of a question to be asked to the bluez developers
> why they even allow the bluez configure script to make udev optional.

Isn't the maintainer supposed to already know?


//Peter

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

[Joshua Kinard]

On 04/05/2014 07:13, Peter Stuge wrote:
> Joshua Kinard wrote:
>> I guess this is more of a question to be asked to the bluez developers
>> why they even allow the bluez configure script to make udev optional.
> 
> Isn't the maintainer supposed to already know?

I would hope so.  The general consensus seems to be, though, that disabling
udev support is non-nonsensical and you lose a lot of bluez's functionality.
 If that is true, why does upstream allow it?  Is it because of some
extremely rare corner case, or is it not as bad as thought?

A look on Wikipedia notes that bluez was originally developed by Qualcomm,
so I'd suspect the optional udev functionality deals with embedded devices
like phones and such that don't need/support udev (i.e., Android).

Your guess is as good as mine.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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