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 <[EMAIL PROTECTED]> wrote:
"Mark Knecht" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 <package> to get a list of merged packages depending on <package>. 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
