[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#685192: apt: redirection handling changes in 0.9.4 may break aptitude



Package: apt
Version: 0.9.4
Severity: grave
Control: affects -1 aptitude
X-Debbugs-CC: mika@debian.org, debian-release@lists.debian.org

Hi,

Michael Prokop noticed that in some cases an aptitude update would fail with 
a "E: Method gave invalid 200 URI Start message" when using http.debian.net.

After a lot of confusion and attempts to debug the problem, in a chroot 
where the issue could be reproduced, I eventually noticed that the versions 
of apt and libapt-pkg4.12 didn't match:

apt: 0.8.15.9 (old version)
libapt-pkg4.12: 0.9.7.2 (wheezy)
aptitude: 0.6.8-1 (wheezy)

The problem:
When aptitude uses libapt-pkg to download a file, it starts an instance of 
the http method that doesn't include the changes made in #668111. This means 
that it sends the 103 redirection message as usual, but it handles it 
internally. Given that aptitude uses libapt-pkg4.12, it handles the 103 
message in the new fashion and starts a new http process to handle the 
redirection.
Since the first http process is handling the request internally, it 
eventually sends a 200 "URI Start" message with the original URI (the one of 
http.debian.net). By then, libapt-pkg4.12 has already marked such URI as 
done, removed it from the http:http.debian.net queue, and more importantly: 
changed the URI of the Itm (pkgAcquire::Queue::QItem). So, when it receives 
the 200 message it can't even match the URI of the message to a QItem, 
therefore aborting with the "E: Method gave invalid 200 URI Start message" 
error.

Why APT still works:
The old apt version works just fine because it uses libapt-pkg4.10, which 
means it handles the redirection internally. According to dpkg -S the 
libapt-pkg4.10 used by apt is provided by the apt package itself. I.e. it is 
not a separate package.

Note: if it is not obvious enough, this isn't restricted to http.debian.net. 
Any mirror that sends a redirection could trigger this bug.


Now, the easiest way to prevent this kind of conflict would be by adding a 
Depends: apt >= 0.9.4 to libapt-pkg4.12. Not sure how much trouble it would 
cause to a squeeze->wheezy upgrade, as it would force apt to also be 
upgraded when upgrading aptitude (upgrading apt already requires upgrading 
aptitude.) It also introduces a soft dependency loop, but it seems harmless.
The alternative way to express it would be by adding a Breaks: apt (<< 
0.9.4) to libapt-pkg4.12. I think this last form would cause more noise 
during the upgrade.

Introducing a new redirection code (104?) would probably cause more trouble 
at this point than handling the problem via the dependencies system.

Toughts?

Sorry for not noticing it before. Somehow I knew I should have bumped the 
redirection code :-/

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


Reply to: