After our first attempt at doing a 6.0 -> 6.1 upgrade failed with a signal 11 and subsequent system halt at the apparent end of the install-updated-RPMs stage (see bug #6913), we felt we had little choice but to retry the upgrade. Doing so resulted in a significantly scrambled RPM database, to wit: The crash of the first install process had apparently left the old versions of a number of upgraded RPMs not removed (at least in the database). When the installer re-ran, it apparently decided that it needed to upgrade them again (despite the presence of the upgraded versions on the system), but then failed to remove the old versions (again). The result, after the upgrade 'completed', was that we had an RPM database and a system with one old copy and two new copies of the same package for quite a few packages. I think that the installer should make more effort to handle previous installations that, for whatever reason (ranging from an installer crash to an inopportune power failure!) have aborted in the middle and are incomplete. As a minimum I would expect it not to re-upgrade packages when the upgraded package is on the system already (it seems likely that this can happen normally, even without the installer failing, with such packages as the kernel). If the installer must bypass ordinary RPM checks, it should make sure that it's not doing evil in the process.
This issue has been forwarded to a developer for further action.
This issue has been added to a list of features for future releases.
This is a very difficult problem but we will consider it for future development.