A quick grep results in alsa-guide.xml articles/lpi-101-administration-p2.xml migration-to-2.6.xml nvidia-guide.xml power-management-guide.xml udev-guide.xml Not all referenced driver ebuilds have been fixed,yet.
Some useful information is required here, namely: How/when are they deprecated (is it an ~arch package? how much time do users have to switch?) If the packages in question haven't been fixed yet, then how am I to fix the docs? Which packages haven't been fixed yet? If not modules.d, what is the correct location? Also, I can't do anything about articles/lpi-101-foo, as articles are marked unmaintained. They are legacy stuff originally copied from IBM developerworks; it's an archive of how things were at the time.
(In reply to comment #1) > Some useful information is required here, namely: > > How/when are they deprecated (is it an ~arch package? how much time do users > have to switch?) This is an open question, I guess. And in the "tradition" of Gentoo we may fail to communicate. vapier summed up¹ the situation - a bit too optimistically regarding the current status, which resulted the tracker bug, this bug is blocking. > If the packages in question haven't been fixed yet, then how am I to fix the > docs? Basically sed -i -e "s:/etc/modules.d:/etc/modprobe.d:g". I'm not sure, if something changed regarding the strictness of the files in these directories or if this is would be relevant to the documentation, though. > Which packages haven't been fixed yet? See bug 215626. > If not modules.d, what is the correct location? See above > Also, I can't do anything about articles/lpi-101-foo, as articles are marked > unmaintained. They are legacy stuff originally copied from IBM developerworks; > it's an archive of how things were at the time. > Expected it, but thought it'd be better to paste the list as is. [1] http://archives.gentoo.org/gentoo-dev/msg_254dcc9705203d8e4515fbcb7a44961d.xml
you can fix docs that are not tied to any package now ... modprobe.d has always worked with all linux-2.6 installs. there is no arch/~arch issue there. only recently have i started to actually push people to make the transition. obviously for docs that refer to a file that a package installs, the relevant package will need to go stable before the related documentation is changed.
(In reply to comment #3) > you can fix docs that are not tied to any package now > obviously for docs that refer to a file that a package installs, the relevant > package will need to go stable before the related documentation is changed. Unfortunately, it looks like just about all our docs that refer to modules.d are in fact for packages that have not yet been fixed, by the look of 'em. - alsa-utils & alsa-lib - nvidia-drivers I can fix a couple of the listings in the udev guide (the non-alsa modules), and for the thinkpad_acpi reference in the power management guide, but that's about it. ALSA and nvidia are the two biggies, so the sooner a fix gets made for those, the sooner I can clean up the docs.
How's this coming? As per comment #4, I'm still waiting on the ALSA and nvidia drivers to be fixed. These done yet? CCing the kernel, alsa, and nvidia-driver maintainers for a response -- is your stuff properly using modprobe.d?
Any new ebuild going in for nvidia-drivers moves the file away from modules.d and into modprobe.d; I'm not comfortable modifying ebuilds that already have stable keywords without a revision bump. As newer kernels require patching and stabilization of newer drivers, I would expect that this problem no longer exists. It's just odd reports of "my extremely specific GeForce 2345XL-super works terribly on anything other then driver 123.45" that keep me from taking the older ebuilds out...
I have checked alsa-utils-1.0.17 (marked as stable on alpha amd64 hppa ppc ppc64 sparc x86) and latest alsa-utils-1.0.19 (marked as testing on all architectures) and both ebuilds install (or move existing) alsa configuration file under /etc/modprobe.d directory. In this respect alsa-utils package seem to be already fixed, but unfortunately it is not as alsaconf by default (invoked without any parameters as suggested in alsa-guide.xml) tries to write to /etc/modules.d/alsa file - which it can't do as /etc/modules.d directory doesn't exist anymore (at least on clean, new Gentoo installments). Since in this situation (where not all parts of alsa-utils are yet aware of the new default modules configuration location), there seems to be discrepancy between what alsa-guide.xml suggests and one can observe while installing new system, I suggest that alsa-guide.xml be updated with information that alsaconf should be run with -c /etc/modprobe.d/alsa parameter.
Fixed in CVS.
