fix progress-segfault in case of dpkg errors/prompts
Errors and conffile prompts have a fourth information piece,
which the "old" code access which isn't provided by the "new" one.
This isn't checking if the messages are really well-formed,
so it could still segfault on misformed messages, but this code
needs more work anyway, so one step at a time.
Michael Vogt [Sat, 5 Oct 2013 10:15:03 +0000 (12:15 +0200)]
* move upgrade releated code into upgrade.{cc,h}
The upgrade releated code is moved into upgrade.{cc,h} and
all pkg*Upgrade* prototypes are included in algorihms.h to
avoid breaking API (unless build with APT_9_CLEANER_HEADERS).
test: use a multiarch capable dpkg rather than workaround
The tests require nowadays a (somewhat) multiarch-capable dpkg, so
replace the workaround as marked in the FIXME with a proper install as
the workaround isn't working always correctly, letting the test fail.
do not ++ on erased package pointers in autoremove
Symptom: In an Ubuntu precise chroot (like on travis-ci)
test-bug-613420-new-garbage-dependency segfaults in a std::set
operator++ on an iterator we have erased previously
(but not if run under gdb of course)
Clear() only clears a config option, not removing it and an empty
setting still exists. Hence we set the option instead to the xz path
so that the later existance check can find a binary for the test
With a bit of trickery we can reuse the usual infrastructure we have in
place to acquire deb files for the 'download' operation as well, which
gains us authentification check & display, error messages, correct
filenames and "downloads" from the root-owned archives.
refactor onError relabeling of DestFile as '.FAILED'
This helps ensure three things:
- each error is reported via ReportMirrorFailure
- if DestFile doesn't exist, do not attempt rename
- renames happen for every error
The last one wasn't the case for Size mismatches, which isn't nice, but
not a exploitable problem per-se as the file isn't picked up and remains
in partial/ where the following download-try will at most take it for a
partial request which fails the hashsum verification later on
We can't remove packages which are held back by the user with a hold, so
marking them (or its dependencies) as garbage will lead our autoremover
into madness – and given that the package is important enough that the
user has held it back it can't be garbage (at least at the moment), so
even if a front-end wants to use the info just for information display
its a good idea to not consider it garbage for them.
Servers might respond with a complete file either because they don't
support Ranges at all or the If-Range condition isn't statisfied, so we
have to parse the headers curl gets ourself to seek or truncate the file
we have so far.
This also finially adds the testcase testing a bunch of partial
situations for both, http and https - which is now all green.
As lengthy discussed in lp:1157943 partial https support was utterly
broken as a 206 response was handled as an (unhandled) error. This is
the first part of fixing it by supporting a 206 response and starting to
deal with 416.
No effective behavior change, just shuffling big junks of code between
methods and classes to split them into those strongly related to our
client implementation and those implementing HTTP.
The idea is to get HTTPS to a point in which most of the implementation
can be shared even though the client implementations itself is
completely different. This isn't anywhere near yet though, but it should
beenough to reuse at least a few lines from http in https now.
replace "filesize - 1" trick in http with proper 416 handling
Our http client requests the "filesize - 1" for the small edgecase of
handling a file which was completely downloaded, but not yet moved to
the correct place as we get 416 errors in that case, but as we can
handle 416 returns now we just special-case the situation of requesting
the exact filesize and handle it as a 200 without content instead.
If we get a 416 from the server it means the Range we asked for is above
the real filesize of the file on the server. Mostly this happens if the
server isn't supporting If-Range, but regardless of how we end up with
the partial data, the data is invalid so we discard it and retry with a
fresh plate and hope for the best.
Old behavior was to consider 416 an error and retry with a different
compression until we ran out of compression and requested the
uncompressed file (which doesn't exist on most mirrors) with an accept
line which server answered with "406 Not Acceptable".
Okay, maybe it does have a "few", but the DDTP issues mentioned in this
file are long since gone, so lets just drop the file and look at the PTS
instead: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=apt
projects / apt.git / log
