[gentoo-amd64] Re: unmerging slotted group packages

[Duncan]

"Daiajo Tibdixious" <daiajo@×××××.com> posted
a4a9bfcb0701272117g58fdd9beof34ecba152619063@××××××××××.com, excerpted
below, on  Sun, 28 Jan 2007 16:17:37 +1100:

> I discovered by accident that I have KDE 3.3, 3.4, & 3.5 all installed
> at the same time.
> I wanted to clean out 3.3 (at least) and tried emerge -aC
> =kde-base/kde-3.3.0 which of course just did this pseudo package, not
> the containing packages.
> I also tried emerge --clean kde-base/kde but this says nothing to
> remove, even though 3.4 & 3.5 are still present:
> [D] kde-base/kde
>      Available versions:  (3.5)  3.5.2 3.5.5
>      Installed:           3.4.3(3.4)(17:19:35 01/18/06)(-accessibility)
>                           3.5.5(3.5)(02:50:53 12/10/06)(-accessibility)
>      Homepage:            http://www.kde.org/
>      Description:         KDE - merge this to pull in all
> non-developer kde-base/* packages
>
> I got rid of 3.3 by doing eix -I kde & removing each sub-package
> manually, I just think I must be missing an easier way.

Two easier ways to do it, but with both, use --pretend first and ensure
it's not going to remove something you know you need.  Both of these
depend on your world file being accurate, so proceed with caution if you
know it's not.  Each separate section is bullet-pointed with **, below,
hopefully making it easy to follow.


** First, some general maintenance.  You may have a bit of cleaning up to
do here if you've not done it in awhile.

There's a step that's normally recommended before the following, only at
this point it'd likely cause a bunch of extra work due to stuff you will
be removing anyway, so I'd say skip it this time.  However, I'll note it
at the bottom under pre-maintenance, and I'd suggest reading thru this
entire message so you understand how it all works, before you start.

OK, do an emerge --pretend --depclean, and see what's listed.  It
should list everything that's not either in your world file or a
dependency of something in your world file.  That's what portage thinks
you don't need.  If you think you need something on that list, do an
emerge --noreplace <package> so portage will add an appropriate entry to
your world file for it.   (If it's a dependency, aka a branch package that
something else depends on, as usual, add the "leaf" packages that depend
on it, thus keeping only "leaves" in your world file, so when all of them
are removed, portage knows it can remove the dependency as well.)

Once you have all the packages in your world file you know you need, so
--depclean --pretend is only listing stuff that should be safe to remove
(it won't be listing the KDE slots stuff at this time, most likely), go
ahead and do the emerge --depclean without the pretend.

That should leave you with all the "extra" packages removed.  Generally,
these will be old dependencies for "leaf" packages, old/dead branches with
no current leaves.  Up to this point you should do relatively frequently,
just keeping the old cruft on your system to a minimum, as part of regular
maintenance.

There is another part to this that you should normally do whenever you are
doing it for system maintenance.  However, we'll skip that here since
it could mean a bunch of extra work for stuff you are going to remove
anyway.  Thus, I'll list it at the bottom, under completing the system
maintenance, after the old-KDE removal stuff.


** OK, now here's method 1, specifically unmerging the old kde slots:

Specifically emerge --unmerge =kde-<old-ver>.  This will unmerge the
meta-package that's the leaf for all the other KDE packages (branches
supporting that leaf) of that version.

** And here's method 2, using --prune:

Emerge --prune will try to unmerge all but the most recently merged version
of the packages in question. That's likely what you want for things like
KDE, but it's definitely NOT what you want for things like autoconf and
automake, for instance, since many packages depend on older versions and
won't work with newer ones.  Thus, ALWAYS use --pretend the first time you
use --prune, just to be SURE it's going to remove what you expect it to,
and nothing else, and NEVER do an emerge --prune world or system (except
if you are curious, you can try it with --pretend, just to see what it
would do if you were stupid and tried --prune world without the pretend).

So... emerge --pretend --prune kde-base/kde, and see what it lists.  If
it looks sensible and it should, run it again without the pretend.

** Finishing up the unmerge:

OK, either way you did it, you should now be clear of the old kde
meta-packages, but you'll still have the actual packages merged.
However, once the metapackage is unmerged, you can again run emerge
--depclean --pretend, and portage should list all the dependencies of the
slot leaf you just removed as stuff it'd now remove.  If it looks correct,
go ahead and do it again, this time without the --pretend. Again, if
there's something listed that you know shouldn't be, do an emerge
--noreplace <package> for it so portage adds it to the world file, then
when everything looks good, go ahead and remove the --pretend.


** Completing the system maintenance, revdep-rebuild:

OK, now you should have all the old cruft removed, but we aren't quite
finished yet.  There's a possibility that some of the remaining packages
are now broken, because they had seen and compiled against some of that
old cruft, even tho they /should/ have compiled against newer stuff. 
Broken dependencies can also happen when you changed USE flags and didn't
recompile everything that used those flags with the new flags.  --depclean
doesn't understand these cases, and so sometimes removes stuff that's
still needed, but there's a tool designed to fix it: revdep-rebuild, which
is part of gentoolkit.

So, if you don't have gentoolkit merged, emerge it.  Then, run
revdep-rebuild --pretend (remember, unlike --depclean, revdep-rebuild is
it's own command, not part of emerge). Depending on the speed of your disk
and amount of memory, revdep-rebuild will take a half an hour or so to
scan all the executables and libraries on your system and ensure they have
all their library dependencies met. If they don't, it'll figure out what
you have to remerge to get things working again, and either do it, or with
pretend, give you a list.  If you've not been keeping up with system
maintenance, especially if you just --depcleaned a bunch of stuff as we
just did, and/or if you don't regularly do emerge --newuse world after
changing your USE flags, you'll likely have a bit of a list of stuff that
needs rebuilt, thus the --pretend the first time, so you get a bit of
warning at how long it might take.

Once you know what revdep-rebuild thinks you need to remerge, you can run
it again without the --pretend, and it'll do it.  (It won't take all that
time figuring stuff out again, as if there's actually anything it needs
to remerge, it saves the work files from the --pretend, so it can get
right to work the second time.)

Once you have everything rebuilt, if you like or I'd recommend it if
you had a lot to rebuild, you can run revdep-rebuild --pretend once more,
just to be sure.  Once it says you are clean, you'll have a nicely
sparkling clean system, freshly de-crufted and with all dependencies
verified by revdep-rebuild.  =8^)


** Pre-maintenance, emerge --newuse and revdep-rebuild:

As I explained near the top, emerge --depclean is an important part of
what should be routine system maintenance, just to keep your system free
of cruft.  However, when done routinely, there's a couple things you can
do before the --depclean to keep things from breaking with the removal
of that cruft and therefore needing rebuilt with revdep-rebuild.  I
suggested skipping them this time only because with all that old stuff on
your system, you'd have likely been doing a lot of extra merging for stuff
that you were just getting ready to clean out.  However, if you do it
routinely, say every three or six months, after any big removals such
as old KDE slots, and after changing your use flags, there won't be that
much stuff out of date anyway, so doing this pre-maintenance is a good
idea as it'll keep stuff from breaking with the --depclean.

For routine maintenance, then, your first steps should be the following:

emerge --newuse world (first with --pretend, or with --ask, of course). 
This makes sure all packages are remerged that have had their USE flags
changed. Since USE flags often determine dependencies, changing USE flags
often means changing dependencies, and remerging any packages with changed
flags then updates the dependencies so they don't break when --depclean
removes stuff based on current USE flags.

revdep-rebuild (again, first with --pretend, or with --ask).  Do this
before your emerge --depclean, after emerge --newuse, and in theory,
nothing should be broken after your emerge --depclean.


** Summary of routine system maintenance, step by step:

Here, in short form and for further reference, are the steps that should
be done routinely, say every 3-6 months, and after USE flag changes or
after major upgrades (stuff like KDE, GNOME, XORG, GCC, etc).

1) emerge --newuse world
2) revdep-rebuild
3) emerge --pretend --depclean
4) emerge --noreplace <package> as necessary
5) emerge --depclean
6) unmerge old slots or major packages if desired
7) repeat steps 3-6 as necessary
8) revdep-rebuild
9) verify with another revdep-rebuild if desired

Nice clean system! =8^)

If done in this order, there shouldn't be much if anything to
revdep-rebuild the second time, in step 8.


** Notes:

- Again, while skipping step 1 and 2 if you haven't been keeping up with
the routine maintenance steps above does mean a bigger risk of stuff
broken, I'd still recommend it in your case right now, simply because it's
likely if you tried doing the above in order, you'd have a lot of packages
to rebuild in steps 1 and 2 only to support stuff you are removing in step
6.  However, if you'd prefer to do the perhaps significant extra work and
avoid as much breakage as possible, go ahead and do it this way this time,
as well.

- revdep-rebuild scans elf files, that is, native elf format binary
executables and shared object libraries.  While that gets most of the big
and critical stuff, revdep-rebuild doesn't understand perl/python/ruby/etc
dependencies, and thus won't rebuild them.  For those types of things,
there are other tools, such as python-updater, for python.

- There's another specialized tool for dealing with all those
*.la libtool files, helping them find libstdc++, as provided by the gcc
package. Every time you unmerge old versions of gcc or when you get
libstdc++ errors trying to merge something, you should run
fix_libtool_files.sh <old/bad-gcc-ver>.  Thus, if you just unmerged or
it's complaining that it can't find the libstdc++ for gcc-3.4.6, for
instance, run fix_libtool_files.sh gcc-3.4.6, and it will scan all the
*.la files it can find and ensure all the entries listing that old
version also list your current gcc version, as pointed at by gcc-config. 
Just another tool to know about, as it sure comes in handy sometimes. =8^)

- I recommend that folks use FEATURES=buildpkg.  That portage feature
causes it to build and archive a binary version of every package it
merges, by default to $PORTDIR/packages.  You can then use emerge
--package (-k) or --packageonly (-K) if for some reason you need to
remerge an old version of something.  This comes in handy in a number of
cases, including if you used --depclean and unmerge something that you
figure out later you needed, but what wasn't in your world file or listed
as a dependency of anything in the world file, for whatever reason. 
Having a couple old versions around in binary package form is also handy
if something stops working right after an upgrade.  Having a binary
package of gcc around is nice as well, in case gcc breaks, and there are
even tricks that allow you to rescue a broken portage or python if you
have a binary package, when you'd otherwise be in pretty bad shape,
because portage is broken and won't let you emerge a new copy of it! 
Typically, packages for an entire system take up about a gig, so plan on
two gigs or so, just to have a bit of extra room.  eclean, now a part of
portage, can be used to manage both your packages dir and distdir, 
pruning old source and package files for ebuilds no longer in the tree.

- If you have emerged a lot of library files and other dependencies
without using --oneshot, so they ended up in your world file, --depclean
won't list or unmerge them when they are no longer needed, because they 
are in your world file.  This is the opposite of the problem above, in
that with the above problem, stuff you need isn't in the world file so
will be removed by --depclean, while here, stuff you no longer need
because it was a dependency of something you are no longer running is
listed in the world file, and thus won't be removed.  There's a tool to
fix this too. =8^)  If you know you have this problem, or just want to see
if you might, try emerging udept, which contains dep.  You can then run
dep --pretend --pruneworld, and get a list of entries in your world file
that it thinks are depends, and thus removable, since something else in
the file depends on them already.  There are a bunch of other things it
can do as well.  It includes its own --depclean implementation, for
instance.  However, while it's often faster than portage, it's also not
always as accurate.  Therefore, as usual, --pretend or --ask can be very
helpful, and you'll want to treat its results rather more skeptically than
you might portage's own.  With --pruneworld, for instance, it wanted to
remove a couple things from world that I found out later I needed there.
Similarly I tried running its depclean, and it wanted to remove QUITE A
FEW packages that were needed, and that portage's depclean knew were 
needed.  So it's a tool that helps, and since it's faster, I'll use it for
some things, but for things like --depclean, I wouldn't trust it at all,
as it DOES get things wrong sometimes, where portage's emerge --depclean
gets it right.

I'm sure that's more information than you had thought you were asking
for, but it's all quite usable here, and hopefully you'll find it equally
so there. =8^)

-- 
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