Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.5 2016-05-28T16:12:02Z 2016-05-28T16:12:02Z David Kalnischkies david@kalnischkies.de 2016-05-28T11:22:38Z urn:sha1:8b79c94af7f7cf2e5e5342294bc6e5a908cacabf We use a wild mixture of C and C++ ways of generating output, so having a consistent world-view in both styles sounds like a good idea and should help in preventing regressions. 2016-04-14T14:15:39Z David Kalnischkies david@kalnischkies.de 2016-04-14T14:01:56Z urn:sha1:e169fa4a85e03b2b03bb1bdba716b96654ae6050 A silly of-by-one error in the stripping of the extension to check for the uncompressed filename broken in an attempt to support all compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5. Fixing this highlights also mistakes in the handling of the Alt-Filename in libapt which would cause apt to remove the file from the repository (if root has the needed rights – aka the disk isn't readonly or similar) 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T12:19:14Z urn:sha1:30c8107e9c56d7d78dcf9136f94aeed9d631dfb3 Continueing on the track of dropping privileges in all methods, lets drop it in copy, too, as the reasoning for it is very similar to file and the interaction between the too quiet interesting as copy kinda surfed as a fallback for file not being able to read the file. Both now show a better error message as well as it was previously claiming to have a hashsum mismatch, given that it couldn't read the file. Git-Dch: Ignore 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T17:49:52Z urn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39 Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore 2015-11-04T17:04:00Z David Kalnischkies david@kalnischkies.de 2015-10-09T20:25:13Z urn:sha1:0940230dd6710ff5b555bed8be3d75ae0d150a08 We drop it in decompressors, which are the natural next step, so if an archive is used which isn't worldreadable (= not accessible by _apt) it doesn't work anyway, so we just fail a bit earlier now and avoid all the bad things which can happen over file (which could very well still be a network resourc via NFS mounts or similar stuff, so hardly as safe as the name might suggest at first). 2015-08-10T15:27:17Z David Kalnischkies david@kalnischkies.de 2015-07-08T22:35:40Z urn: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 2015-06-15T21:35:54Z David Kalnischkies david@kalnischkies.de 2015-06-15T11:36:11Z urn: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. 2015-06-15T12:39:37Z David Kalnischkies david@kalnischkies.de 2015-06-15T10:51:22Z urn: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. 2015-06-09T10:57:35Z David Kalnischkies david@kalnischkies.de 2015-06-06T10:28:00Z urn: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(). 2015-04-18T23:13:09Z David Kalnischkies david@kalnischkies.de 2015-03-30T18:47:13Z urn: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.