In some rare situations a bad update is pushed that then needs to be blocked from users. We should provide some explaination when this happens. Currently it will just display a 403 error without further details. So its unclear to the user if its a intentional blocked update or a problem on the server.

Release Note



The current approach of chmod 000 results in 403 errors. This is confusing for our users as no further information is conveyed.

User stories

Jill is a ubuntu user and wonders why the machine suddenly returns 403 errors on upgrade (she does not know what this means). Instead a proper explanation should be given.


We need to cover two cases:

To cover the individual package problems we continue with the "chmod 000" approach. But we also add a $name.busted (or broken?) file so that apt can check for this and offer a different error message in this case that explains that its a temporary problem.

For the archive-in-bad-shape state we add a new key "Broken" key to the meta-release file that update-manager will read. If it encounters it it will abort the upgrade with a explaination. If update-manager auto-opens and the archive is in broken state it should just exit silently.


See work items in the blueprint.

Test/Demo Plan

We need to add a meta-release test file on a different location that contains a "Broken: yes" key to test the update manager integration. We also need a test archive that contains some deb packages with chmod 000 and .busted files so that apt can be tested and integration with the higher level tools (software-center, synaptic).

BoF agenda and discussion

Bad updates in Ubuntu

Issue for this session

The main issue for this session is when the repository is inconsistent

Maybe have a meta-file on supported flag or new key in meta-release "busted"

You get an HTTP 403 error message and you're not sure why

What happens if we catch the error after it's been mirrored? [james_w]

Show the error only if people are actively trying to do something that would harm them

If Update Manager would open automatically but it knows the updates it would install won't work, then ... it shouldn't open automatically, but instead exit silently if the archive is not doing well (because it does not know before it was not started)

If someone launches it manually ... just say "Updates aren't available at the moment. Try again later."

Problem space



FoundationsTeam/Specs/LucidUpdateManagerStopTheLine (last edited 2009-11-29 11:20:10 by mvo)