Ubuntu – Strategy to deal with Canonical’s increasingly poor QA

Whenever you open or execute a file in Windows, Windows locks the file in place (this is a simplification, but usually true.) You may have encountered those annoying errors where you can't delete a file because another process has an exclusive lock on it. This is why whenever Windows has to update itself you need a reboot for it to take effect. Windows will queue up file replacement and deletion activities for when it next boots up (when nothing has a lock on anything.)

On the other hand, Linux has a mechanism wherein it's not the file that is locked but the underlying data on the disk that is. This may seem a trivial differentiation but it means that the file's record in the filesystem's table of contents can be deleted without disturbing any program that already has the file open. So you can delete a file while it is still executing or otherwise in use and it will continue to exist on disk as long as some process has an open handle for it even though its entry in the file table is gone. This allows Linux to replace a program completely while it's still running and then simply restart the program or just wait for the process to exit naturally. Once the old instance is killed, the old files will no longer exist at all and the new files will have taken up residence in their entries in the file table.

So, as long as a particular file is not special in some way (like, for example, the kernel image file or files belonging similarly low-level systems) the updater can usually update-in-place like this. I'm sure there are special cases and situations where this would not be a good idea, but for most cases it's fine.

As for why OS X does it, that "just in case" theory sounds plausible.

Summary

_{or "I don't really care if I keep messing things up and wasting my and others' time with preventable problems, and you have 30 seconds to convince me to care!"}

If you use Update Manager to upgrade your packages, and it offers to do a "Partial Upgrade", do not accept it without thoroughly checking what packages it offers to remove, upgrade and install. If you do, you will most likely end up removing packages that shouldn't be removed, and waste time and effort repairing your installation and asking for assistance.

Most "Partial Upgrade" situations occur due to package archive inconsistencies, which will typically be resolved within a few hours. If your package manager is confused, and so are you, simply wait and hold off the updates until things settle down.

Short Version

_{or "Hmm, so I shouldn't blindly do "Partial Upgrade"s and dist-upgrade? I didn't know that..."}

Due to the fact that uploads & replications to mirror repositories are sometimes not synchronous, dependencies of certain packages may arrive later than the dependent package. This causes package management tools such as Update Manager to interpret the situation as requiring a dist-upgrade to install new packages and/or repair packages in a "reqreinst" (requires reinstallation) state. What Update Manager performs when doing a "Partial Upgrade" is a dist-upgrade.

Most of the time, a "Partial Upgrade" is undesired. The situations where it's needed are limited to new packages obsoleting old ones (as in the case of the software-center package replacing software-store) and package removals from the archive.

Long Version

_{or "I think I know what I'm doing! Tell me more!"}

In its normal operating mode, Update Manager will not offer to remove packages. This is the equivalent of "apt-get upgrade"ing your existing packages. In "Partial Upgrade" mode, it can. Sometimes, the removal is warranted, such as when a package is obsoleted by a new one. Other times, it will not be, and a "Partial Upgrade" can offer to remove important packages due to missing dependencies.

Now, the key question:

"How do I know whether a package is actually meant to be replaced or removed?"

There's more than one way:

• Check the changelog of the package in question. You can do this via "Package > Download Changelog" in Synaptic, or "aptitude changelog package_name", or by going to packages.ubuntu.com and clicking "Ubuntu changelog" for the package you're curious about, or visiting the URL

  https://launchpad.net/ubuntu/+source/package_name/+changelog

• where package_name is the name of the source package you're curious about. The most recent changelog entry will indicate the reason for the removal or replacement, if there is one.

  For an example scenario of using the list of recent changes to determine whether a package removal and "Partial Upgrade" is safe, refer to the next post.

• Check the build status information page for Ubuntu and the queue of new uploads to the Ubuntu release (e.g. Natty) on Launchpad to see if those mysterious missing dependencies are coming down the pipes, or there are problems preventing them from being built.

• Do a forum search/AskUbuntu, or join the #ubuntu+1 channel on irc.freenode.net and ask around to see whether other people are having problems with the same package(s).

• If you're still confused, simply wait and see if things are magically fixed within a few hours. If not, start a new thread or post to an existing one on the same issue to check with others.

A typical interaction with a package manager involves the following three steps:

1. You select some packages to be installed / removed / upgraded

2. The package manager resolves your intention according to its package management logic, the available software sources, and the priorities you've indicated (as in APT pinning), if any, to a set of actions it has to perform, and outputs a list of those actions

3. You check this list, confirm it if you're happy with it, or cancel it and refine your selection until you're happy with it.

If you skip the third step, assuming that simply updating your package information and hitting "Apply" or pressing "Enter" when the prompt comes up will give you the latest changes - you'll break your installation unnecessarily. Don't do that. Review that list of changes.

all credit to 23meg Ubuntu QA Team