Update addiction - how to avoid problems

[lars_msh]

This is a general overview of how to manage software updates aimed at relatively inexperienced users (like me!) It's largely subjective based on my own experience, and focuses on the pitfalls of doing too much "emerge -u world" (that is, "emerge --update world").

Firstly, it's worth remembering that no system is perfect, especially in the world of online software updates. I've used Windows Update, Mandrake Update and Red Carpet, and of course emerge, and had problems with all of them. That's life.

So here are a few things I'd suggest to avoid problems. Forgive my habit of stating the obvious. This isn't advanced stuff.

1. Timing of updates

Chances are most of your updates will run flawlessly, but there's no accounting for Sod's Law. When it does go wrong, it will happen at a bad time.

Don't do what I did. While I was staying with my fiancee over Christmas, I thought it would be cool to ssh into my box at home and update my Gentoo system. I figured it would save a backlog of updates after a two week break. End result? I came home to the usual stuff: backlog of chores, affairs to deal with, returning to work, loads of e-mail to read and sort out... and a system with damn near unreadable fonts!

If you're busy, typing "emerge sync" and "emerge -u world" only takes seconds out of your schedule, but fixing any problems could take a lot longer. Try to avoid updates at such busy times; doubly so if you use your system for something important, e.g. working from home.


2. Frequency of updates

This is obviously down to personal choice, your Internet connection, CPU speed and personal obsession. It might help to bear in mind that many updates are very small, and an update in the Gentoo system doesn't necessarily mean the actual program is updated.

It's all in the version number:

dev-php/php-4.3.0-r2

The 4.3.0 is PHP's own version number. The r2 is Gentoo's ebuild version number. So if you updated PHP to

dev-php/php-4.3.0-r1

and a few days later "emerge -up world" shows the -r2 file, it may not be absolutely vital, or even particularly useful, to update the package.

Even when PHP 4.3.1 does come out, it might just contain a few bug fixes relating to FreeBSD, enhanced Oracle connectivity and localisation enhancements for Chinese systems. Chances are this won't all apply to you, so unless you read the ChangeLog you don't know if you'll gain anything at all from upgrading.

Increasing the time between updates will mean less time spent downloading minor updates to software, and less time spent recompiling software on account of ebuild revisions.

On the other hand, if you leave it too long (months) between updates, you may find the impact on your system somewhat greater, and it will be harder to identify and fix problems in the update.

3. Updating config files

For info about this, type:

emerge --help config

Resist the temptation to let non-updated config files build up. If you think you're spending too long looking through and updating config files, you're probably updating the system too often!

4. What to not update

This is a very personal decision, although an important consideration here is security.

I am feeling relatively safe behind my NAT router with my machine here at home, so if the odd package doesn't get updated the same day as a security flaw is announced, chances are I'll be ok. Where security is an issue, you should obviously be more aggressive with updating packages and looking out for known security flaws, workarounds and fixes.

However, in a more general sense, this is my view: the packages I use most, I'm finding it best not to blindly update them with "emerge -u world", for the simple reason that if X, Mozilla or something like that blows up at the wrong moment, it's a major pain in the arse.

This may seem a little odd, but the best time to update XFree86 is on a Sunday morning [or insert your favourite quiet moment here] when you're reading on the Gentoo forums how cool version 4.x.x is at rendering 8pt sans-serif fonts against a grey background and you just have to try it out for yourself. When you have the time for it, you can "emerge -up xfree", etc. and spend some hours playing around with it until it finally does what you want.

In the meantime, edit the file

/var/cache/edb/world

and delete the line pertaining to xfree. Also I would delete other big ones, like KDE, Gnome, Mozilla, Evolution, VMWare (that's another one I managed to upgrade at an inconvenient moment without paying much attention).

You can also delete the lines for applications you've installed and don't really use or care about, but aren't quite ready to delete. Why track incremental changes of package foo 1.0.1, 1.0.2 etc. when you only use it every three months?

A smaller world file results in a smaller output of "emerge -up world", so significant updates that might be problematic are less likely to go unnoticed.

...and if you do want to track updates to a package, I think I'm right in saying you should emerge it explicitly if you want it to go into the world file. That is, emerging "Kfoo", where Kfoo is a KDE app, will probably emerge KDE and XFree86 for you if you don't already have them, but only Kfoo will be in your world file.

5. Not updating the kernel

This is a special case of (4) above that I thought worth mentioning; it's another pitfall I stumbled into.

How often do you recompile your kernel? Not often in my case, my uptime is usually 1-2 months between power failures and other 'mishaps', and frankly I don't really see the need (see security notes above though). However, if you followed the install instructions, you'll have entered a command like this (depending on your chosen kernel):

emerge sys-kernel/gentoo-sources

and thus the kernel sources package was duly entered into your world file, to be updated along with "emerge -u world".

What happend to me was this: my kernel sources were updated from 2.4.19 to 2.4.20, and later on my 2.4.19 got cleaned out. Whether this was automatic, or as a result of my doing "emerge clean", I'm not sure, although I suspect the latter. The result was that I didn't have the source code corresponding to my running kernel. Not fatal, but try installing vmware when uname -a says "2.4.19" and "/usr/src/linux" is a symlink to 2.4.20.

The solution was to emerge the 2.4.19 sources explicitly:

emerge /usr/portage/sys-kernel/gentoo-sources/gentoo-sources-2.4.19-r10.ebuild

If you don't recompile your kernel often, you can avoid problems by taking it out of your world file.

6. What to update

Firstly, you don't have to update world, you can update system:

emerge -up system
emerge -u system

Secondly, when you do an "emerge -up world", you can look at the output as a way to see what's new, and if only a couple of packages (Foo, and Bar) seem relevant, you can:

emerge -up foo bar
emerge -u foo bar

Still use the pretend flag, because you need to know what dependencies will be updated... you might be bringing a major Gnome/XFree86 update upon yourself in this 'minor update'.

7. View the Changelog

(this section newly added)

Further to the above, especially the security section, it's probably a good idea to make a habit of looking at the Changelog files. You can find these in your portage tree.

Example: I have mozilla-1.2.1-r4 installed; it seems to be working fine. What reason to upgrade to mozilla-1.2.1-r5 (the latest update currently showing)?

The way to find this out is to look in /usr/portage/net-www/mozilla/ and look for the ChangeLog file. Here I see that, since the last build, a memory leak has been fixed, which is nice, but in the real world this doesn't seem to have affected me. There's also sparc support, which I guess won't do much for my P4, and a fix for crashing on startup, which I guess doesn't apply either as I'm using Mozilla now!

So, why risk this happening at an inconvenient moment? I think I'll wait for a quiet moment to upgrade, or wait for an -r6 and fix more bugs with one recompile.

What you do with your Mozilla is of course your own business, but the ChangeLog will help in making that decision!

8. Finally... be nice

Not related just to this topic, but I normally do

nice emerge -u world

This runs it with a lower priority (i.e. nicely!), so the system won't feel as slow during compilation.


Bottom line: it's usually best to look before you emerge; portage only seems to be magic!

[divisor]

Well done ;)
_________________
/chu.

[shm]

Also, for updating, I recommending emerging "ccache" before. It speeds up updading A LOT (about 4-5 times the speed here, unless it's a real major upgrade)

[kormoc]

Deleted

[shm]

[itsr0y]

Very nice document. Well written and quite helpful!

[nikai]

Well done! Only a small objection:

[lars_msh]

[BlackBart]

if you edit your world file make sure you don't do an "emerge dep-clean" because that will wipe out all the packages you took out.

[roovis]

Maybe a new feature could be added to skip certain packages on emerge -u world, but not have to remove them from the world file?

[peterk0]