1i5t5.duncan at cox
Mar 10, 2010, 1:34 PM
Post #8 of 10
Paul Stear posted on Wed, 10 Mar 2010 08:05:32 +0100 as excerpted:
Re: Failures on updating KDE to 4.4.1 - unable to update kmail
[In reply to]
> I have just un-installed amarok and am starting to upgrade world
> including mysql etc.
One additional thing I should mention. For me it's routine so sometimes I
forget that it may not be that way for everyone.
The scriptlets I normally use to upgrade all use -NuD, so an update is
always a FULL update, all the way thru the dependencies (deep), and
updating any packages with changed USE flags as well. Personally, I don't
have much use for half-way updates, as I believe they'll cause me more
pain than the time they'll save.
Similarly, I always finish with a scriptlet that runs lafilefixer
--justfixit, and then revdep-rebuild $* -- -a1. (Actually, it's slightly
more complicated than that, as I source a config file that sets a parallel
jobs environmental variable, and add that variable to the revdep-rebuild
command line as well, so it takes advantage of portage's parallel emerge
features where it can.) Of course, Between lafilefixer and the fact that
I run as-needed in my LDFLAGS, my revdep-rebuild load is far lower than it
would be otherwise, which helps. =:^)
Then another scriptlet runs emerge --ask --depclean, and if it cleaned
anything major, I run the rebuild scriptlet again just to double-check
that the removals didn't leave any hanging needed rebuilds.
Of course, another scriptlet takes care of the etc-updates.
So when I'm done, not only are all dependencies deep updated along with
all packages with new USE flags, but I've ensured all stale linkages are
fixed and removed all the old no longer depended packages as well,
rerunning the stale linkages check after the cruft removal.
I also take care to read all the elogged messages (or at least skim them,
as most are repeats I'm familiar with by now) and do all the config
I'm unsure how many problems such a thoroughly proactive update regime
saves me, but I'm sure it's non-zero. If you're not regularly running
revdep-rebuild after updates, try it, with --ask or --pretend first, as
you may have quite a few rebuilds built up the first time you run it. The
--newuse and --deep emerge flags are mostly me being extra cautious (plus
I just like being updated thru and thru), as in theory they shouldn't be
needed. But it shouldn't need stated that theory doesn't always match
reality. And if you're not running emerge --depclean routinely, do be
extremely careful the first few times you run it, absolutely run it with
--pretend the first time, and go thru its list looking for stuff you want
to keep and add it to your world file (emerge --select --noreplace),
before running --depclean for real. Removing that cruft does help because
sometimes packages get mixed up and link to the old versions, if they're
still around. Plus, there's potential security vulns to think about,
since they're no longer in the dependency tree portage checks for updates.
Using such a program, you should proactively avoid many problems, and then
you'll be the one shrugging your shoulders and saying "it works for me."
=:^) Of course it won't fix them all, but the ones that are left are much
more likely to have real bugs associated with them, not the fuzzy bugs
associated with a system not kept in peak running order.
(Also keep in mind that perl-cleaner and python-updater are the parallel
to revdep-rebuild in their respective language domains. But unless you're
doing python/perl development or scripting on your own, it's unlikely
you'll need them as often as revdep-rebuild, as the number of apps using
them isn't as high, and the usage isn't as "system-core", as C/C++.)
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