From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M0zaK-0007Ew-52 for garchives@archives.gentoo.org; Mon, 04 May 2009 14:56:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 92469E0407; Mon, 4 May 2009 14:55:58 +0000 (UTC) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 3EBC5E0407 for ; Mon, 4 May 2009 14:55:58 +0000 (UTC) Received: by ewy9 with SMTP id 9so3580824ewy.34 for ; Mon, 04 May 2009 07:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=ct2BGXdBBnzmtfuUihKmfE4781AEuOUxuDfg6q+XCrE=; b=mCqmZsv6zUBdLB9tGOqemjYlPgamk6muPiesdd9ioKKc8yQZKzae+x3xLKMepEYET4 9/s1VxaMu+cqKefvc4yULInMP7ctuUFgtz74/S7yOyixYXb4ZLgKRj/hiLqI99aXidSd SBg+M9CVfHFo/YOQ3BsV2+FUsjnm+vItydhBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=kYuxJwRGX7L0QGhnNS/PKUvW0+pwYmWV5GNJucyPk07mQ2wRzlYZU1Vt+R/0BkPBir gyKV2bZF/4chP6Qt44s+WmOvspzBf1ApIwYl3QCXjCHawJGjARt4JBaZ89TChoXuKFgq ScyMvQAYEVvPVy1GjG7288joDPcYXVRG+HSJE= Received: by 10.210.81.10 with SMTP id e10mr6235918ebb.86.1241448957700; Mon, 04 May 2009 07:55:57 -0700 (PDT) Received: from nazgul.localnet (196-210-140-95-rrdg-esr-2.dynamic.isadsl.co.za [196.210.140.95]) by mx.google.com with ESMTPS id 28sm3612122eye.16.2009.05.04.07.55.56 (version=SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 07:55:57 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Removing Packages with Portage Date: Mon, 4 May 2009 16:54:21 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.29-gentoo-r1; KDE/4.2.2; x86_64; ; ) References: <200905041308.53676.alan.mckinnon@gmail.com> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905041654.21337.alan.mckinnon@gmail.com> X-Archives-Salt: ac001d2f-0fac-44e6-a115-eabc9595f1be X-Archives-Hash: 5d261b0b433cbd262b5e7b3f4cc4619c 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/ > > > > 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 /-. 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//// 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 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