| 1 |
> Out of tree kernel modules are a maintenance pain in the ass, and cause |
| 2 |
> severely non-obvious problems like this. Every time you upgrade your kernel, |
| 3 |
> you must rebuild the out-of-tree modules, and you do that by re-running |
| 4 |
> "emerge madwifi-ng". This builds a new modules that matches the currently |
| 5 |
> configured kernel (/usr/src/linux/) and puts the module in |
| 6 |
> /lib/modules/<version> |
| 7 |
> |
| 8 |
> Upgrade your kernel a few times and you have various versions of modules |
| 9 |
> floating around. Portage remembers the modules installed by the most recent |
| 10 |
> emerge, but AFAIK forgets all the previous ones. This is expected of course - |
| 11 |
> when you upgrade firefox-2 to firefox-3 you would not expect the system to |
| 12 |
> remember the firefox-2 files (as they are supposed to not be there anymore) |
| 13 |
|
| 14 |
Your explanation is extremely helpful here. Thanks! As long as I |
| 15 |
know the expectation, I can plan for it when troubleshooting. I can |
| 16 |
certainly see the 'pain in the ass' factor there. :-) I was |
| 17 |
originally chasing a panic caused by ath_pci - but now that I've |
| 18 |
looked more closely at the issue that you describe here, I see that I |
| 19 |
did manage to get 2 incompatible interdependent modules installed in |
| 20 |
the system...grrr. I'll be doing some more-than-casual tinkering with |
| 21 |
ath_pci vs ath5k in the coming weeks, so I'll probably just plan not |
| 22 |
to use that ebuild for the present moment. :-) Although....would it |
| 23 |
be non-trivial for me to try and extend the ebuild to make it clean up |
| 24 |
after itself on unmerge? |
| 25 |
|
| 26 |
Along the same lines, how does the ebuild know what to remove on |
| 27 |
--unmerge? For example I'm wandering around and looking at ebuilds: |
| 28 |
|
| 29 |
prometheus ethtool # pwd |
| 30 |
/usr/portage/sys-apps/ethtool |
| 31 |
prometheus ethtool # ls |
| 32 |
ChangeLog Manifest ethtool-6.ebuild metadata.xml |
| 33 |
prometheus ethtool # |
| 34 |
|
| 35 |
I see nothing in that ebuild which describes the files that ethtool |
| 36 |
put on the system. Yet an --unmerge removes the binaries and |
| 37 |
source....interesting. |
| 38 |
|
| 39 |
So I found a CONTENTS file: |
| 40 |
|
| 41 |
prometheus ethtool-6 # pwd |
| 42 |
/var/db/pkg/sys-apps/ethtool-6 |
| 43 |
prometheus ethtool-6 # cat CONTENTS |
| 44 |
dir /usr |
| 45 |
dir /usr/sbin |
| 46 |
obj /usr/sbin/ethtool e830749ff2f81cc25b6629b19e93e3e7 1241002052 |
| 47 |
dir /usr/share |
| 48 |
dir /usr/share/doc |
| 49 |
dir /usr/share/doc/ethtool-6 |
| 50 |
obj /usr/share/doc/ethtool-6/NEWS.bz2 8757829b0fb19bb74c968c203fc76b68 |
| 51 |
1241002049 |
| 52 |
obj /usr/share/doc/ethtool-6/AUTHORS.bz2 |
| 53 |
11b48a9d12c1cebcb2ae6bb29e80d1e1 1241002049 |
| 54 |
obj /usr/share/doc/ethtool-6/ChangeLog.bz2 |
| 55 |
08b981d7a1afb29bbac1636ae81026c2 1241002049 |
| 56 |
obj /usr/share/doc/ethtool-6/README.bz2 |
| 57 |
3188a9ad571f7e4e4d0c1df4479db6d4 1241002049 |
| 58 |
dir /usr/share/man |
| 59 |
dir /usr/share/man/man8 |
| 60 |
obj /usr/share/man/man8/ethtool.8.bz2 71a609e8a269cc9dcc0e813e77675ab6 |
| 61 |
1241002049 |
| 62 |
prometheus ethtool-6 # |
| 63 |
|
| 64 |
Based on this, it looks like portage internally records the files |
| 65 |
which get installed.....and then can retrieve this information later |
| 66 |
(qfile might want this information, --unmerge might want it...etc.). |
| 67 |
Is this the correct way to understand how portage maintains sanity? |
| 68 |
|
| 69 |
Thanks! |
| 70 |
|
| 71 |
-- |
| 72 |
Matt |
Archives