From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1H12L6-0002G9-80 for garchives@archives.gentoo.org; Sun, 31 Dec 2006 15:11:08 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kBVF9E0B018098; Sun, 31 Dec 2006 15:09:14 GMT Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kBVF9EMP031486 for ; Sun, 31 Dec 2006 15:09:14 GMT Received: by nf-out-0910.google.com with SMTP id c31so10167221nfb for ; Sun, 31 Dec 2006 07:09:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lZzgEFZOkgzTmZg1K1s70R+seKmw9343sqMdpYdO6Ntk9QTU8EjmuR5G0NWNVk488cTOiEq3mxofQmKssIyRH/Gwj8bVJS8MUe+w9ex86qRrJXYMrvczxqYHMjX1978a9kN3oLe6lIlTQa2DcfqukKNrKx7RTLlOazAxnOf3DQY= Received: by 10.82.183.19 with SMTP id g19mr1020678buf.1167577754088; Sun, 31 Dec 2006 07:09:14 -0800 (PST) Received: by 10.82.106.18 with HTTP; Sun, 31 Dec 2006 07:09:14 -0800 (PST) Message-ID: <5bdc1c8b0612310709y43c07aa5qcb8cb967d16dd32e@mail.gmail.com> Date: Sun, 31 Dec 2006 07:09:14 -0800 From: "Mark Knecht" To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: emerge --depclean question In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5bdc1c8b0612301751k5f65c464nf8b9bd99c3b75091@mail.gmail.com> X-Archives-Salt: a124b5fe-a480-432f-968b-5666ba6b1dff X-Archives-Hash: 124ad61caeb29693fa2842de02264c19 Duncan, Makes perfect sense. Thanks. I'll spend some time today grinding through all this stuff and get it cleaned up. Thanks, Mark On 12/31/06, Duncan <1i5t5.duncan@cox.net> wrote: > "Mark Knecht" posted > 5bdc1c8b0612301751k5f65c464nf8b9bd99c3b75091@mail.gmail.com, excerpted > below, on Sat, 30 Dec 2006 17:51:29 -0800: > > > I haven't done this in quite awhile so this evening I started > > looking at dependencies a bit. I thought I might take a shot at > > cleaning things up old stuff left around from updates over the last > > year or so. I ran emerge -p --depclean and was told that there were > > about 45 things to remove so I decided I'd try removing a few > > one-at-a-time and see how it went. First I sync'ed and did an emerge > > -DuN world and made sure the machine was up to date. I then removed > > what seemed like a pretty random entry late on the list - imlib - and > > then a revdep-rebuild -p to see what it thought. I was then told I > > needed to emerge revisions of two new things - gnome-lib and > > gtk-pixbuf - neither of which existed according to both emerge and > > eix. I then re-emerged imlib, reran revdep-rebuild and now I see the > > machine is consistent again. > > gnome-lib and gtk-pixbuf are GNOME-1. Somewhere, you still have something > wanting GNOME-1 stuff, which has been removed from the tree as nothing > current depends on it. > > You can use equery -d to get a list of merged packages depending > on . Try that with gnome-lib and see what comes up. Maybe you > don't need it any more and can unmerge it. Or, if it's still in the tree > the dependencies must now be fixed, so remerging it should kill the > dependencies on gnome-lib. (equery is part of gentoolkit.) > > It's also possible you have "orphaned" libraries around that somehow got > left behind after an unmerge. Portage won't know about these so > --depclean won't consider them. However, revdep-rebuild does a scan of > the actual libraries and applications you have, including orphans and > binary-only packages (which remerging won't fix since you just remerge the > same binary libraries with the same compiled in dependencies), and thus > catches things portage wouldn't. > > > Is this a question that certain ebuilds are not written correctly > > and don't somehow call for the right dependencies, or is it something > > else? > > It's probably either packages that have changed since you merged them, or > orphans, as mentioned above. It could however also be just as you said, > dependencies that aren't properly noted in the ebuild. This can be either > a missed dependency that needs to be there, or something the package > configure script detected on its own, that wasn't part of the ebuild. > Gentoo devs try not to have any of those "autodetected" things, because it > causes problems exactly like what you are seeing. Instead, they try to > specify a hard dependency if the package really needs it, make it > conditional on a USE flag if it's optional, or unconditionally tell the > config script NOT to use it if Gentoo has a different way of handling it > or something, as sometimes happens. However, sometimes upstream changes > the dependencies or optional dependencies and the Gentoo devs don't catch > the changed config it until someone runs into problems and files a bug. > > > Also, is there any better tool these days for cleaning up stale > > packages left around than emerge --depclean? > > Not really... that I know of anyway. There are a few other tools such as > dep, from the udept package, but it's worse, not better. (From what I can > tell, it checks the dependencies in the ebuilds themselves but not the > ones brought in by the eclasses, so it misses some. It's quite a bit > faster, but it's also not anywhere near as dependable.) > > Basically, it's a process of using --depclean -p, and getting a list, then > using common sense and trial and error to figure out what's safe to remove > and what's not. It's not an easy or simple process, which is why there > are such big warnings on it. However, it's worthwhile to do once in > awhile, both because it helps keep the troubles away, and because stuff > that it says needs removed is stuff portage won't be regularly updating, > and that can quickly become a security issue if there's a vulnerability in > one of those packages. > > One thing that makes things MUCH easier, however, and you may already be > doing this, is using FEATURES=buildpkg. If you are, testing unmerges is > vastly easier, since if something needs the package, you can simply emerge > -k the binary package that was created during the initial merge -- that's > what the buildpkg feature DOES. > > If you haven't been using the buildpkg feature, it's also possible to > quickpkg the package already on your system before you remove it. Again, > if it turns out you actually need it, you don't have to spend all that > time recompiling it, all you have to do is emerge -k it, to remerge the > binary package you created using quickpkg. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > -- > gentoo-amd64@gentoo.org mailing list > > -- gentoo-amd64@gentoo.org mailing list