A quick summary first. There are some ebuilds which install various firmwares and have the following RDEP (stolen from sys-firmware/iwl1000-ucode): || ( >=sys-fs/udev-096 >=sys-apps/hotplug-20040923 ) From what I understand: 1. We do not really support hotplug anymore, 2. practically it is not possible to use one app as a device manager, and other one as a firmware loader. Solution A: 1. Add IUSE=firmware-loader to virtual/dev-manager which will enable only those device managers which can load firmware (so only udev at this point), 2. change the dependency to virtual/dev-manager[firmware-loader]. Solution B: Just drop the dependency, and assume that if user decides to use a dev-manager without firmware loading support, he's on his own.
the savy user can choose to build required firmware into the kernel .. thus udev is not needed all the time and should be optional .. I do this with one configuration on my laptop and it works well so far.
(In reply to comment #1) > the savy user can choose to build required firmware into the kernel .. thus > udev is not needed all the time and should be optional .. I do this with one > configuration on my laptop and it works well so far. In that case, I would vote for just dropping the dependency.
(In reply to comment #1) > the savy user can choose to build required firmware into the kernel .. thus > udev is not needed all the time and should be optional .. I do this with one > configuration on my laptop and it works well so far. That's not always an option -- there's plenty of things that I keep as modules because either the driver or firmware or both aren't reliable enough to be compiled in and I need to unload them ocasionally. That said, I would expect that most ppl who do this won't be using an alternative to udev and so #2 may sitll be the easiest option. Would it be possible to at least elog or otherwise warn users about this (when using a virtual/device-manager that isn't a udev)?
(In reply to comment #3) > That's not always an option -- there's plenty of things that I keep as > modules because either the driver or firmware or both aren't reliable enough > to be compiled in and I need to unload them ocasionally. > > That said, I would expect that most ppl who do this won't be using an > alternative to udev and so #2 may sitll be the easiest option. Would it be > possible to at least elog or otherwise warn users about this (when using a > virtual/device-manager that isn't a udev)? The only way to do this would be to add ewarns to pkg_postinst in every ebuild as we drop the dependency on udev. If I do that I would prefer that it be conditional, based on whether or not udev is installed. Can has_version be used to test this without testing for a specific version number? Also, Is my understanding correct that there are situations when the kernel can load firmware directly without something like udev? If so, what are those situations?
(In reply to comment #4) > (In reply to comment #3) > > That's not always an option -- there's plenty of things that I keep as > > modules because either the driver or firmware or both aren't reliable enough > > to be compiled in and I need to unload them ocasionally. > > > > That said, I would expect that most ppl who do this won't be using an > > alternative to udev and so #2 may sitll be the easiest option. Would it be > > possible to at least elog or otherwise warn users about this (when using a > > virtual/device-manager that isn't a udev)? > > The only way to do this would be to add ewarns to pkg_postinst in every > ebuild as we drop the dependency on udev. If I do that I would prefer that > it be conditional, based on whether or not udev is installed. Can > has_version be used to test this without testing for a specific version > number? Also, Is my understanding correct that there are situations when the > kernel can load firmware directly without something like udev? If so, what > are those situations? Unless I am wrong, without udev, firmware must be built into the kernel. This means the warning in these ebuilds would need to be something like: if ! udev_installed; then warn about building firmware into the kernel fi I just need to look into testing for udev being installed without requiring a specific version.
(In reply to comment #4) > (In reply to comment #3) > > That's not always an option -- there's plenty of things that I keep as > > modules because either the driver or firmware or both aren't reliable enough > > to be compiled in and I need to unload them ocasionally. > > > > That said, I would expect that most ppl who do this won't be using an > > alternative to udev and so #2 may sitll be the easiest option. Would it be > > possible to at least elog or otherwise warn users about this (when using a > > virtual/device-manager that isn't a udev)? > > The only way to do this would be to add ewarns to pkg_postinst in every > ebuild as we drop the dependency on udev. If I do that I would prefer that > it be conditional, based on whether or not udev is installed. Agreed, though I'm not sure if we want to keep that many copies of something so specific. Maybe we should introduce an eclass for firmwares? > Can has_version be used to test this without testing for a specific version > number? Yes, I think so. > Also, Is my understanding correct that there are situations when the > kernel can load firmware directly without something like udev? If so, what > are those situations? Just as a note for those not participating in IRC discussion, mdev wiki page mentions something about firmware loading when only one firmware is available[1]. I have no idea whether it is relevant to either compiling-in or the specific driver. I've opened a talk on wiki[2] to see if someone could give some insight. [1]:http://wiki.gentoo.org/wiki/Mdev#ATI.2FAMD_binary_blobs [2]:http://wiki.gentoo.org/wiki/Talk:Mdev#Firmware_loading
The kernel might soon be able to load firmware directly from filesystem: http://marc.info/?l=linux-kernel&m=134928559202065&w=2
(In reply to comment #7) > The kernel might soon be able to load firmware directly from filesystem: > http://marc.info/?l=linux-kernel&m=134928559202065&w=2 What's the latest here, do we have a stable kernel which can load firmware directly from the fs? If so, I think we can just drop the dependencies on udev.
(In reply to comment #0) > A quick summary first. > > There are some ebuilds which install various firmwares and have the > following RDEP (stolen from sys-firmware/iwl1000-ucode): > > || ( >=sys-fs/udev-096 >=sys-apps/hotplug-20040923 ) Darn, I didn't notice this bug and removed hotplug from the || () dependencies around the tree because hotplug is now p.masked for removal. It just makes spotting of these plain firmware packages a bit harder. Anyone got a list?
Solution B from Comment #0 is the way to go here. But this bug doesn't block any other bugs, and there is no list provided. I'm thinking closing this as NEEDINFO and suggesting to file separate bugs on per package basis for the maintainers of the redudant dependency.
(In reply to comment #9) > (In reply to comment #0) > > A quick summary first. > > > > There are some ebuilds which install various firmwares and have the > > following RDEP (stolen from sys-firmware/iwl1000-ucode): > > > > || ( >=sys-fs/udev-096 >=sys-apps/hotplug-20040923 ) > > Darn, I didn't notice this bug and removed hotplug from the || () > dependencies around the tree because hotplug is now p.masked for removal. > It just makes spotting of these plain firmware packages a bit harder. Anyone > got a list? Phew. Figured a way to easily track down those obvious ones. These are the ones I've touched according to ^ $ grep -r -i remove.*sys-apps.*hotplug */*/ChangeLog app-emulation/xen-tools/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt media-tv/ivtv/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/at76c503a/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/atmel-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/i2400m-fw/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/ipw2100-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/ipw2200-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/ipw3945-ucode/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/prism54-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/rt2860-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/rt2870-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/rt61-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/rt73-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/zd1201-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt net-wireless/zd1211-firmware/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt sys-fs/iprutils/ChangeLog: Remove sys-apps/hotplug dependency from || () in favour of virtual/udev wrt
Everything from Comment #11 now fixed. Looking at: http://qa-reports.gentoo.org/output/genrdeps/rindex/virtual/udev I don't see anything more to fix. I think we can actually close this as FIXED now.