[gentoo-amd64] Re: Failures on updating KDE to 4.4.1 - unable to update kmail

[Duncan]

Paul Stear posted on Wed, 10 Mar 2010 08:05:32 +0100 as excerpted:

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

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