apt/test/integration/test-apt-redirect-loop, branch 2.7.10Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.7.102016-08-24T08:24:41Zdo fail on weakhash/loop earlier in acquire2016-08-24T08:24:41ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-24T07:47:48Zurn:sha1:2e2865ae53a65c00dd55a892d5b48458f3110366
The bugreport shows a segfault caused by the code not doing the correct
magical dance to remove an item from inside a queue in all cases. We
could try hard to fix this, but it is actually better and also easier to
perform these checks (which cause instant failure) earlier so that they
haven't entered queue(s) yet, which in return makes cleanup trivial.
The result is that we actually end up failing "too early" as if we
wouldn't be careful download errors would be logged before that process
was even started. Not a problem for the acquire system, but likely to
confuse users and programs alike if they see the download process
producing errors before apt was technically allowed to do an acquire
(it didn't, so no violation, but it looks like it to the untrained eye).
Closes: 835195
detect redirection loops in acquire instead of workers2016-08-10T21:19:44ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-02T20:44:50Zurn:sha1:57401c48fadc0c78733a67294f9cc20a57e527c9
Having the detection handled in specific (http) workers means that a
redirection loop over different hostnames isn't detected. Its also not a
good idea have this implement in each method independently even if it
would work