Scott James Remnant

It also seems that several of the dapper to edgy upgrade problems are caused by the use of Automatix; a tool to perform common customisations to Ubuntu, such as replace the pre-installed software with alternatives and install packages that Ubuntu is unable to pre-install due to patent or other legal issues.

Henrink has a few good points about this, however I feel that it’s also important to remember that the Ubuntu community does not only consist of the core developers.

Automatix, and its like, are by their very definition, tools to reduce the amount of your system that the core developers will support. The default set of installed packages is not arbitrary, and one may be selected over your preferred solution simply because we do not have the expertise in the team to deal with the other, or even because the other is not supported upstream!

We therefore rely on the wider community to take ownership of these packages, and support them within the community structure.

Support, in the development sense, doesn’t just consist of security updates either; it also consists of keeping the software up to date, fixing bugs, and most importantly of all; testing it before we release.

The right approach to making sure that Automatix users are not bitten again during the edgy to feisty upgrade in 6 months time is for members of the community to come together and form a team to support it. The existing Automatix team in Launchpad is probably a good start.

One of the goals of this team should be to make sure that throughout feisty’s development cycle, upgrading from an edgy box with Automatix installed works flawlessly. Where it doesn’t, they should take effort to ensure that useful bugs are filed (e.g. “foo 1.1-2 contains same file as bar 1.0-1 but neither Replaces nor Conflicts it”) so that the problems can be fixed.

Likewise where community members suggest that a user install software from outside the main component, or even outside the Ubuntu repository entirely, they should keep in mind that they’re likely to cause that user problems when it’s time for upgrade.

If you’re running a repository of your own right now, have you considered that you need to start testing upgrades from edgy with your packages installed to feisty? Testing when feisty releases is too late!

It seems that some people with heavily customised Ubuntu installations have had problems upgrading from dapper to edgy. While we do test upgrades as much as we can, there’s no way to test every possible permutation, so problems do creep in.

Here’s a checklist to perform before upgrading to minimise any problems you might have:

• Make sure you have the ubuntu-minimal and ubuntu-desktop packages installed (Kubuntu, Xubuntu, etc. should use the appropriate meta-packages for their distribution). This may require removing some replacement programs you have installed, but you can always put those back after the upgrade process.
• Check for any locally installed packages, you can use aptitude search '~i!~Oubuntu' to get a list of them. Some of these may cause conflicts with the upgrade process, it may be worth removing them and putting them back after the upgrade.
• If you have manually installed any software from upstream, and not used Ubuntu packages (especially the Nvidia or ATI binary drivers), revert those to the Ubuntu-provided versions before upgrading.
• Use the update manager, as described in the release notes, and not apt-get dist-upgrade. While the latter may work eventually, it will require more manual tinkering than the automatic upgrader.

If, after taking all of these precautions, your upgrade still fails; please file a bug report, and try to include as much information as possible. Provide the list of packages that failed, and if possible the error message provided by them. Provide /var/log/dpkg.log and the files in /var/log/dist-upgrade.