404 from the archive is not handled well

We have various options here:
- show a proper error message
- offer reload button
- reload list automatically on 404 and try again once that is finished

In what sort of situation would reloading the list fix this problem?

Hi Matthew,

The situation reloading the lists would fix this in is when a new version of the package you are trying to install has been released, so the old one has been removed from the mirrors but is still referenced in your local package list. This causes software center (or any package manager) to try to download the old, non-existent file, resulting in the 404. Reloading the package list will get the information about the new package version and try to download that instead, which solves the 404.

This is more likely to happen during a beta as well, since so many packages are being updated so often.

-Dan

The error message comes from the curl library. aptdaemon only gets the error string from python-apt. we would have to parse the string and guess. so we only know that there was an error fetching a package file.

But we could enhance the error dialog to show a button to run a update-cache transaction and improve the error message.Currently it reads: Failed to download package files. Check your Internet connection.

A current example of this is bug 838217. If you try to install the package from USC, it just fails silently.

Should we check if the cache has been updated in the last 24 hours? If this is the case we could show an alternative error message suggesting to re-updating the list. But we could also perfrom an update-cache operation automatically by aptdaemon.

I like Michael's third suggestion: if we get a 404, automatically reload the list and try again. If we fail a second time, then show a nice error message.

What should the message say? "Check your Internet connection" doesn't seem appropriate for a 404. Maybe "Try again in a few hours"?

We cannot reduce this to a 404 error - since we don't know what happened. The download just fails. Kind of a black box.

The next question is if we should do this inside of the transaction or create a new update-cache transaction and requeue the current one.

Why don't we know what happened? Does aptdaemon not have access to the HTTP status code?

right. There are several software stacks involved: software-center -> dbus -> aptd -> python-apt -> libapt -> libcurl

We only get a possible translated error message from libcurl.

I've written up a first draft of a solution to this. <https://wiki.ubuntu.com/SoftwarePackageOperations#download-failed> In brief, when a download fails: First check whether there's an Internet connection, and complain about that if necessary. Second, try downloading the package list again, and if that fails, complain that the software channel is not available. But if it succeeds and the URL has changed, try downloading the file again, and if that fails, complain specifically that the file is missing.

Sebastian, does that make sense? The design assumes that the errors will be presented by Aptdaemon, not by USC. That cuts out two layers from the software stack, making it a little more likely that we might be able to get even smarter (e.g. distinguishing between 403 and 404 errors) in future.

Am Dienstag, den 08.05.2012, 23:42 +0000 schrieb Matthew Paul Thomas:
> I've written up a first draft of a solution to this.
> <https://wiki.ubuntu.com/SoftwarePackageOperations#download-failed> In
> brief, when a download fails: First check whether there's an Internet
> connection, and complain about that if necessary. Second, try
> downloading the package list again, and if that fails, complain that the
> software channel is not available. But if it succeeds and the URL has
> changed, try downloading the file again, and if that fails, complain
> specifically that the file is missing.
>
> Sebastian, does that make sense? The design assumes that the errors will
> be presented by Aptdaemon, not by USC. That cuts out two layers from the
> software stack, making it a little more likely that we might be able to
> get even smarter (e.g. distinguishing between 403 and 404 errors) in
> future.

I am not sure where to place all this logic. Perhaps we need some kind
of high level client / error handler in aptdaemon or move those bits
into software-center, but this would make sharing with update-manager or
any other client harder.

The tough challenge is to integrate the problem notification dialog and
the resolution confirmation dialog into one single dialog.

I will think about it and talk to mvo.

Mathew, please don't mark unrelated bugs as duplicates.