On Monday 04 May 2009 14:11:02 Matt Causey wrote: > > 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.
Love gotta love gentoo - break it, you get to keep both pieces :-) > 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? " Portage keeps it's house-keeping in /var/db/pkg with subdirectories in the form <category>/<package>-<version>. There's interesting stuff in there, like a file called CONTENTS. It has the files installed by the ebuild, plus their md5sums, and that's how portage knows what to rm when you unmerge. "man ebuild" lists the functions you can override in ebuilds, including unmerge. It calls pkg_postrm (a simple bash function) so you could in theory insert a call to "find /lib/modules" to find all the modules in question and delete them. You'd have to think this through carefully though as the potential for destruction is vast... > 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. Portage runs the ebuild in a restricted directory - /var/tmp/portage/<category>/<package>/<work>/ and all the built files end up there, in a directory structure that mirrors the root filesystem layout. "man ebuild" has all the gory details. Try this: run "ebuild /usr/portage/sys-apps/ethtool-6.ebuild install" and examine /var/tmp/portage/sys-apps/ethtool/work. Note that you emerge a *package name* but ebuild an ebuild *file* (much the same way yum install and rpm -ivh do it). That command will run all the ebuild steps up to and including install, but the files are not yet on the lie filesystem. "ebuild <file> merge" does that, skipping all steps already completed. It then locates every file in the tmp directory and moves them onto the live filesystem, recording what it finds. This list is what goes in CONTENTS. Simple, hey? Virtually every tool out there which gives you information on installed packages (except eix, that also uses huge chunks of voodoo), looks in /var/db/pkg/, which explains why it's so slow - 1462 directories and 35847 files on this box is a lot of stuff to stat and read -- alan dot mckinnon at gmail dot com
