apt can't open package cache under certain circumstances

[Álvaro M. Recio]

Binary package hint: apt

The problem in apt I'm reporting can be triggered through "Muon updater". I originally reported the bug to KDE but the author of Muon suggested me reporting the problem here, as it was an apt problem.

The following is the original bug report about Muon updater (https://bugs.kde.org/show_bug.cgi?id=265741):

----------------------------------------------------------------

Version: 0.2 (using KDE 4.6.0)
OS: Linux

Please bear with me as this is a rather difficult bug to explain and reproduce.

The problem appears when there are pending updates after a repository refresh
(apt-get update), those updates are not applied and, later, Muon updater is
opened (it will show the updated packages), the repositories are updated again
and a newer version of one of the pending packages is found.

My personal theory is that Muon updater still tries to mark the old packages
which are now not present in the repositories, as a newer version of them was
released. Anyway, I don't know Muon internals, so I could be completely wrong.

Reproducible: Always

Steps to Reproduce:
1. Add a frequently update repository to "Software sources" (for example,
Chromium Daily PPA, https://launchpad.net/~chromium-daily/+archive/ppa).
2. Reload the repositories (apt-get update).
3. Hopefully, there will be pending updates. Muon will report them.
4. Don't reload the repositories until there are newer version of those
packages (Chromium Daily should publish new packages every day).
5. Without reloading, open Muon updater. It will show the same old pending
updates.
6. Refresh the repositories from Muon updater (Check for Updates).

Actual Results:
Muon updater will show an error dialog (the following is an approximate
translation from the Spanish version):

"The package system couldn't be started. Your configuration may be defective.
Details:
A file for package $PACKAGE couldn't be located. This could mean that you will
have to manually fix that package."

("El sistema de paquetes no se ha podido iniciar. Su configuración puede estar
defectuosa.
Detalles:
No se pudo localizar un archivo para el paquete $PACKAGE. Esto puede significar
que necesita arreglar manualmente este paquete.")

Expected Results:
Muon updater should have suggested the newer version of the package as an
update candidate without showing an error message as the update can be
performed the next time Muon is opened.

OS: Linux (x86_64) release 2.6.35-25-generic
Compiler: cc

----------------------------------------------------------------

The following is the replly of the author of Muon (https://bugs.kde.org/show_bug.cgi?id=265741#c1):

This is an issue with APT itself not being able to open the package cache. I
would recommend reporting this bug at Launchpad:
https://bugs.launchpad.net/ubuntu/+source/apt/

[Torsten Spindler (tspindler)]

Can you reproduce this error with only using apt-get?

[Jonathan Thomas (echidnaman)]

No, since apt-get doesn't reopen the package cache over the course of the program. (It's single-shot)

[David Kalnischkies (donkult)]

I don't know what "reopen" means here, but if it uses pkgCacheFile it should throw away the entry instance and create a new one. pkgCache, depCache and all the others are using IDs to reference packages/versions/descriptions/whatever which are not stable between binary cache regenerations. If it doesn't it still has to throw away all these stuff, but it should consider using it as its easier to reuse instead of generating all the different caches "by hand".

At least, i don't see what could be a bug in APT here as python-apt gets it right -- it is now able to even change the native architecture while running in multi-arch context, so i am setting it back to incomplete…

[Jonathan Thomas (echidnaman)]

(Putting back to new as discussed at UDS)

[Julian Andres Klode (juliank)]

"(Putting back to new as discussed at UDS)" is not an explanation for a status change. Please summarize the discussion.

[Jonathan Thomas (echidnaman)]

Ah, sorry forgot about this. At UDS David and I initially discussed it and did agree that the error was coming from APT. I had to get somewhere so I quickly came here and sent the bug back to new. We later went through QApt's code and found that its function for calculating download used a fetcher that could potentially raise errors. These errors were not being cleared from APT's error system, so when QApt went to reload the cache the errors would still be there, tripping up QApt in to thinking that the cache reload failed.

QApt now discards all errors incurred in its downloadSize() function, fixing this issue. I'd like to apologize for not giving a decent explanation for setting the bug back to new, and for forgetting about the Launchpad bug for this long after UDS.