Edgy in the news

Michael Vogt mvo at ubuntu.com
Tue Oct 31 15:51:25 GMT 2006

On Sun, Oct 29, 2006 at 08:26:09PM +0000, m c wrote:
> On 10/29/06, Daniel Robitaille <robitaille at fastmail.fm> wrote:
> > The negative stories and blogs about Edgy are
> > starting to pile up:
> >
> > Upgrading to Ubuntu Edgy Eft a "Nightmare"
> > http://linux.slashdot.org/linux/06/10/28/239258.shtml
> >
> > Edgy upgrade pains and fixes
> > http://www.desktoplinux.com/news/NS3291004537.html
> Although it is very difficult to diagnose problems from blog and forum
> posts (hence the analysis below is probably wrong, incomplete and
> unhelpful) I think a large number of problems fall into the following
> categories:

Thanks for taking the time to look at the reports out there. I went
through a lot of slashdot comments to see what kind of problems were
reported there and came to similar conclusions. 

I would encourage everyone with upgrade problems to report them in
launchpad (if not reported there already) so that we get better
data. Together with the log files from /var/log/dist-upgrade this
should give us a very good overview what goes wrong and what needs to
be done to fix the problems.

For the bugreports we got so far via launchpad we have better figures
and I started with a spec to analyse the problems and find solutions
to improve the upgrade experience. It can be found here:

> * Using apt-get dist-upgrade rather than upgrade-manager
>    - Could this be  reduced by emphaising on the release notes, on
> ubuntu.com and in the support channels, the correct way to upgrade?

I think we should make it clearer in the ReleaseNotes that using
apt-get dist-upgrade means that people have to double-check for
ubuntu-desktop after the upgrade. 

> * Having unsupported programs and scripts run on Dapper, i.e.
> Automatix, compiz, etc
>    - Could be improved by forcing people to use upgrade manager and
> making update manager identify specific problems then giving more
> verbose instructions on how to revert/work around changes made by
> these programs which are likely to result in a broken upgrade

Update-manager is doing this for e.g. the common problem that the
unofficial compiz repository has higher version numbers than the edgy
packages and this prevented a upgrade for a lot of people. But to work
around this, we first need to know about it. 
> * Broken X on upgrade
> No matter what the specific problem:
>    - Implementation of the fallback/unbreakable X spec could prevent
> users from ending up in this situation by falling back on vesa with
> easy instructions to get back to accelerated X

I think this is really needed.
> Would  making the CD install create a separate home partition by
> default encourage using CD installs for upgrades rather than updating,
> and would this be desirable?

I think we should make sure that we get upgrades working as reliable
as we can. Obviously this is not a easy task because there are just
too many ways that a system can be customized. 

The current upgrader tries to ensure that, but the problems have shown
that it needs to do better and that we need more testing from
"real-world" systems. This is currently a problem, most people wait
until very late to upgrade and so the bugreports come in very late too
about the real-world problems. Something like "simulate upgrade"
feature that would do a simulated upgrade in a chroot would be
good. This way our users could test the process without risking
trouble on their real system. 


More information about the sounder mailing list