> Out of tree kernel modules are a maintenance pain in the ass, and cause > severely non-obvious problems like this. Every time you upgrade your kernel, > you must rebuild the out-of-tree modules, and you do that by re-running > "emerge madwifi-ng". This builds a new modules that matches the currently > configured kernel (/usr/src/linux/) and puts the module in > /lib/modules/<version> > > Upgrade your kernel a few times and you have various versions of modules > floating around. Portage remembers the modules installed by the most recent > emerge, but AFAIK forgets all the previous ones. This is expected of course - > when you upgrade firefox-2 to firefox-3 you would not expect the system to > remember the firefox-2 files (as they are supposed to not be there anymore)
Your explanation is extremely helpful here. Thanks! As long as I know the expectation, I can plan for it when troubleshooting. I can certainly see the 'pain in the ass' factor there. :-) I was originally chasing a panic caused by ath_pci - but now that I've looked more closely at the issue that you describe here, I see that I did manage to get 2 incompatible interdependent modules installed in the system...grrr. I'll be doing some more-than-casual tinkering with ath_pci vs ath5k in the coming weeks, so I'll probably just plan not to use that ebuild for the present moment. :-) Although....would it be non-trivial for me to try and extend the ebuild to make it clean up after itself on unmerge? Along the same lines, how does the ebuild know what to remove on --unmerge? For example I'm wandering around and looking at ebuilds: prometheus ethtool # pwd /usr/portage/sys-apps/ethtool prometheus ethtool # ls ChangeLog Manifest ethtool-6.ebuild metadata.xml prometheus ethtool # I see nothing in that ebuild which describes the files that ethtool put on the system. Yet an --unmerge removes the binaries and source....interesting. So I found a CONTENTS file: prometheus ethtool-6 # pwd /var/db/pkg/sys-apps/ethtool-6 prometheus ethtool-6 # cat CONTENTS dir /usr dir /usr/sbin obj /usr/sbin/ethtool e830749ff2f81cc25b6629b19e93e3e7 1241002052 dir /usr/share dir /usr/share/doc dir /usr/share/doc/ethtool-6 obj /usr/share/doc/ethtool-6/NEWS.bz2 8757829b0fb19bb74c968c203fc76b68 1241002049 obj /usr/share/doc/ethtool-6/AUTHORS.bz2 11b48a9d12c1cebcb2ae6bb29e80d1e1 1241002049 obj /usr/share/doc/ethtool-6/ChangeLog.bz2 08b981d7a1afb29bbac1636ae81026c2 1241002049 obj /usr/share/doc/ethtool-6/README.bz2 3188a9ad571f7e4e4d0c1df4479db6d4 1241002049 dir /usr/share/man dir /usr/share/man/man8 obj /usr/share/man/man8/ethtool.8.bz2 71a609e8a269cc9dcc0e813e77675ab6 1241002049 prometheus ethtool-6 # Based on this, it looks like portage internally records the files which get installed.....and then can retrieve this information later (qfile might want this information, --unmerge might want it...etc.). Is this the correct way to understand how portage maintains sanity? Thanks! -- Matt
