| Summary: | net-wireless/bluez-bluefw-1.0 shouldn't depend on hotplug | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Heiko Baums <heiko.baums> |
| Component: | New packages | Assignee: | Alastair Tse (RETIRED) <liquidx> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mobile+disabled |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Heiko Baums
2006-08-12 05:42:28 UTC
without any context except for the hpilp bug, i don't quite understand what the problem is since i have both hotplug and udev installed and they don't seem to conflict. but nevertheless, i'll change the dep to hotplug-base. hope that somehow solves the issue for you. bluez-bluefw isn't really required for more modern kernels because /lib/firmware/ supercedes it. but if you are using an older kernel, then maybe you still require it. I guess bluez-bluefw was installed as a dependency and wasn't uninstalled by emerge --depclean. If it's not needed anymore I'll try to uninstall it. As you possibly know there are many and long discussions about inconsistant linkings for some devices like /dev/cdrom, /dev/cdrw etc. in the forums. Many people including myself have the problem that randomly after each reboot sometimes /dev/cdrom is their CD-ROM drive and /dev/cdrw is their CD-RW burner and sometimes it's vice versa. Additional there are sometimes links like /dev/cdrom1 which are randomly linked against different devices. Another problem is that some udev rules for some usb devices like setting the owner and group for the usb scanner are ignored even if they look correct. After searching and reading a lot in the forums and in bugzilla I had the idea to uninstall hotplug and delete the directories /etc/hotplug*. After this and rebooting the system every problem with the device links and the udev rules were fixed without changing anything else. The device links are consitant and link to the correct devices and the udev rules are applied again so that the correct permissions are set again. That's why I suppose that there is a conflict between hotplug and udev. And, btw., hotplug isn't needed anylonger if a newer udev version with built in hotplug functionality is installed. ;-) If you have both udev and hotplug installed you have the same software installed twice. It's not quite unusual that this can lead to conflicts. And thanks for the fix. :-) ok, that does seem to make sense to me. i suppose because i have one of everything, this never really happens to me. but it might explain on my machine why i'm able to use udev to rename only one of my network devices and not the other as maybe hotplug is interfering with udev's operation. btw, i should also make explicit, bluez-bluefw is replaced by bluez-firmware which recent kernel modules will use the built in firmware loading features and will search /lib/firmware/. you only need bluez-firmware if you have a non-CSR (cambridge silicon radio) bluetooth device. bluez-firmware looks more familiar than bluez-bluefw. So I'll uninstall it. I don't know if I really need firmware related package for a simple bluetooth dongle to connect to a cell phone. I think you should just try it out and also unmerge hotplug. I guess then you can rename your other network devices again. After my next emerge -uDN world which is hopefully in about 1 1/2 or 2 days I'll search the forums again and post the hotplug/udev thing in a more appropriate place and/or file another bug/feature request that the udev ebuild should not only block coldplug but also hotplug. |
