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