27746 2003-09-01 18:47 0000 numerous ebuilds have an unnecessary dependancy on alsa-drivers 2004-03-16 10:22:18 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED P2 normal --- 1 lv@gentoo.org eradicator@gentoo.org agenkin@gentoo.org aliz@gentoo.org games@gentoo.org kde@gentoo.org sound@gentoo.org x86-kernel@gentoo.org lv@gentoo.org 2003-09-01 18:47:01 0000 Please dont mark this as a duplicate of but 14907, as it is a seperate issue and not directly related to virtuals. The problem is, most ebuilds that depend on alsa-driver dont make use of the headers or anything else that comes from that package. lordviram portage # fgrep -r media-sound/alsa-driver `ls | grep -v -e 'packages' -e 'profiles' -e 'scripts' -e 'sec-policy' -e 'metadata' -e 'sys-'` | wc -l 57 that might be a slightly misleading number... but I'm thinking maybe a couple of those need actually need alsa-driver and that's being generous. What many of these ebuilds mean to do is make sure you have a runtime capability for using alsa. For this they should use an RDEPEND on virtual/alsa or if they already have a DEPEND on alsa-lib no mention of anything else (the dependency is already filled by alsa-lib). These packages dont /need/ alsa-driver to compile and during runtime there are a number of packages which can satisfy this dependancy other than media-sound/alsa-driver. The virtual/alsa already exists to satisfy runtime dependencies and points towards media-sound/alsa-driver. When the switch to linux 2.6 happens, updating /all/ of those ebuilds will be as simple as changing that virtual if they are made to use the alsa virtual. As an added benefit, those who use alternative kernels can easily add theirs to this virtual if it provides kermel alsa support. Right now the best you can hope for is staying somewhat up to date in your own local portage tree. Reproducible: Always Steps to Reproduce: 1. emerge mm-sources 2. emerge anything that uses alsa 3. watch emerge bitch bitch bitch bitch bitch eradicator@gentoo.org 2004-03-13 03:16:03 0000 These are the only ebuilds that DEPEND on alsa-driver, so I'm including their maintainers to get a fix (I'll take care of the media-* ones this weekend). games-emulation/stella/stella-1.3.ebuild kde-base/kdelibs/kdelibs-3.0.5b-r1.ebuild media-libs/alsa-lib/alsa-lib-0.9.0_rc2.ebuild media-sound/alsamixergui/alsamixergui-0.9.0.1.2-r2.ebuild media-sound/alsamixergui/alsamixergui-0.9.0.1.2.ebuild media-sound/alsamixergui/alsamixergui-0.9.0.1.2-r1.ebuild wolf31o2@gentoo.org 2004-03-13 08:28:14 0000 games-emulation/stella is fixed in CVS caleb@gentoo.org 2004-03-16 05:20:05 0000 kde depends on alsa-lib and virtual/alsa. Is this wrong? eradicator@gentoo.org 2004-03-16 08:35:53 0000 virtual/alsa is for the driver... so if you need the headers provided by the alsa-driver or kernel, then that's what you need to DEPEND on. lv@gentoo.org 2004-03-16 10:02:58 0000 almost nothing should depend on alsa-driver... almost nothing needs those headers. though, since i moved over to an amd64 box, this hasnt been as much of an issue. there must be some virtual that prevents alsa-drivers from installing, since the 2.4 kernel isnt supported on amd64 and so alsa-drivers should never ever be installed. *shrug* eradicator@gentoo.org 2004-03-16 10:16:34 0000 Travis: virtual/alsa is provided by the 2.6.x kernel and media-sound/alsa-driver. Additionally, you should be able to use >=media-sound/alsa-driver-1.0.2c instead of the one that is included in the kernel if that is your desire. just waiting on the kde-base/kdelibs/kdelibs-3.0.5b-r1.ebuild switch from alsa-driver to virtual/alsa... caleb@gentoo.org 2004-03-16 10:19:53 0000 kdelibs is now fixed eradicator@gentoo.org 2004-03-16 10:22:18 0000 great, thanks.