Re: [gentoo-amd64] Re: emerge --depclean question

[Mark Knecht]

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@×××.net> wrote:
> "Mark Knecht" <markknecht@×××××.com> posted
> 5bdc1c8b0612301751k5f65c464nf8b9bd99c3b75091@××××××××××.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 <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@g.o mailing list
>
>
-- 
gentoo-amd64@g.o mailing list