apt/methods/file.cc, branch 1.1.exp11Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.1.exp112015-08-10T15:27:17Zadd c++11 override marker to overridden methods2015-08-10T15:27:17ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-08T22:35:40Zurn:sha1:3b3028467ceccca0b73a8f53051c0fa4de313111
C++11 adds the 'override' specifier to mark that a method is overriding
a base class method and error out if not. We hide it in the APT_OVERRIDE
macro to ensure that we keep compiling in pre-c++11 standards.
Reported-By: clang-modernize -add-override -override-macros
Git-Dch: Ignore
call URIStart in cdrom and file method2015-06-15T21:35:54ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-15T11:36:11Zurn:sha1:ff86d7df6a53ff6283de4b9a858c1dad98ed887f
All other methods call it, so they should follow along even if the work
they do afterwards is hardly breathtaking and usually results in a
URIDone pretty soon, but the acquire system tells the individual item
about this via a virtual method call, so even through none of our
existing items contains any critical code in these, maybe one day they
might. Consistency at least once…
Which is also why this has a good sideeffect: file: and cdrom: requests
appear now in the 'apt-get update' output. Finally - it never made sense
to hide them for me. Okay, I guess it made before the new hit behavior,
but now that you can actually see the difference in an update it makes
sense to see if a file: repository changed or not as well.
ensure valid or remove destination file in file method2015-06-15T12:39:37ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-15T10:51:22Zurn:sha1:9f697f69cf1adaced476598cfe08ab03c76c5d18
'file' isn't using the destination file per-se, but returns another name
via "Filename" header. It still should deal with destination files as
they could exist (pkgAcqFile e.g. creates links in that location) and
are potentially bogus.
rework hashsum verification in the acquire system2015-06-09T10:57:35ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-06T10:28:00Zurn:sha1:448c38bdcd72b52f11ec5f326f822cf57653f81c
Having every item having its own code to verify the file(s) it handles
is an errorprune process and easy to break, especially if items move
through various stages (download, uncompress, patching, …). With a giant
rework we centralize (most of) the verification to have a better
enforcement rate and (hopefully) less chance for bugs, but it breaks the
ABI bigtime in exchange – and as we break it anyway, it is broken even
harder.
It shouldn't effect most frontends as they don't deal with the acquire
system at all or implement their own items, but some do and will need to
be patched (might be an opportunity to use apt on-board material).
The theory is simple: Items implement methods to decide if hashes need to
be checked (in this stage) and to return the expected hashes for this
item (in this stage). The verification itself is done in worker message
passing which has the benefit that a hashsum error is now a proper error
for the acquire system rather than a Done() which is later revised to a
Failed().
calculate only expected hashes in methods2015-04-18T23:13:09ZDavid Kalnischkiesdavid@kalnischkies.de2015-03-30T18:47:13Zurn:sha1:9224ce3d4d1ea0428a70e75134998e08aa45b1e6
Methods get told which hashes are expected by the acquire system, which
means we can use this list to restrict what we calculate in the methods
as any extra we are calculating is wasted effort as we can't compare it
with anything anyway.
Adding support for a new hash algorithm is therefore 'free' now and if a
algorithm is no longer provided in a repository for a file, we
automatically stop calculating it.
In practice this results in a speed-up in Debian as we don't have SHA512
here (so far), so we practically stop calculating it.
send Alt-* info for uncompressed based on any compressions2015-04-18T23:13:09ZDavid Kalnischkiesdavid@kalnischkies.de2015-03-27T18:59:44Zurn:sha1:a09f6eb8fc67cd2d836019f448f18580396185e5
file sends information about the uncompressed file if it can find it as
well as for the compressed file. This was done only for gzip so far, but
we support more compression types. That this information isn't used a
lot is a different story.
Git-Dch: Ignore
cleanup headers and especially #includes everywhere2014-03-13T12:58:45ZDavid Kalnischkiesdavid@kalnischkies.de2014-03-05T21:11:25Zurn:sha1:453b82a388013e522b3a1b9fcd6ed0810dab1f4f
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.
Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
Fix typos in documentation (codespell)2014-02-22T17:34:33ZMichael Vogtmvo@debian.org2014-02-22T17:34:33Zurn:sha1:1e3f4083db29bba600b9725e9456b0e140975c99try to avoid direct usage of .Fd() if possible and do read()s and co2011-12-17T22:53:31ZDavid Kalnischkieskalnischkies@gmail.com2011-12-17T22:53:31Zurn:sha1:109eb1511d0cdfa4af3196105cada30bcbb77bc8
on the FileFd instead
use forward declaration in headers if possible instead of includes2011-09-19T17:14:19ZDavid Kalnischkieskalnischkies@gmail.com2011-09-19T17:14:19Zurn:sha1:472ff00ef2e48383805d281c6364ec27839e3f4d