Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.2 2017-01-19T02:57:45Z 2017-01-19T02:57:45Z David Kalnischkies david@kalnischkies.de 2017-01-19T02:57:45Z urn:sha1:7ca83492e802967f183babf06ab541b1b51f1703 If apt renames a file to .FAILED it leaves its namespace and is never touched again – expect since 1.1~exp4 in which "apt clean" will remove those files. The usefulness of these files rapidly degrades if you don't keep the update log itself (together with debug output in the best case) through and on 99% of all system they will be kept around forever just to collect dust over time and eat up space. With this commit an update call will remove all FAILED files of previous runs, so that the FAILED files you have on disk are always only the ones related to the last apt run stopping apt from hoarding files. Closes: 846476 2016-05-04T10:12:33Z David Kalnischkies david@kalnischkies.de 2016-05-04T09:45:35Z urn:sha1:5a23c56d6852a27d45c2ae227b43060f7beac051 Most tests just need a signed repository and don't care if it signed by an InRelease file or a Release.gpg file, so we can save some time by just generating one of them by default. Sounds like not much, but quickly adds up to a few seconds with the amount of tests we have accumulated by now. Git-Dch: Ignore 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-04-24T08:35:08Z urn:sha1:30979dd7616105302f06af82f419eb62d7b613f8 They are the small brothers of the hashsum mismatch, so they deserve a similar treatment even through we have for architectual reasons not a much to display as for hashsum mismatches for now. 2016-03-16T16:56:50Z Julian Andres Klode jak@debian.org 2016-03-16T15:46:39Z urn:sha1:f695e76199a43b7f4d5816e20d18496b6448b833 This makes it easier to understand what really is an error and what not. 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore 2015-11-04T17:42:27Z David Kalnischkies david@kalnischkies.de 2015-10-28T13:38:49Z urn:sha1:1dd20368486820efb6ef4476ad739e967174bec4 Based on a discussion with Niels Thykier who asked for Contents-all this implements apt trying for all architecture dependent files to get a file for the architecture all, which is treated internally now as an official architecture which is always around (like native). This way arch:all data can be shared instead of duplicated for each architecture requiring the user to download the same information again and again. There is one problem however: In Debian there is already a binary-all/ Packages file, but the binary-any files still include arch:all packages, so that downloading this file now would be a waste of time, bandwidth and diskspace. We therefore need a way to decide if it makes sense to download the all file for Packages in Debian or not. The obvious answer would be a special flag in the Release file indicating this, which would need to default to 'no' and every reasonable repository would override it to 'yes' in a few years time, but the flag would be there "forever". Looking closer at a Release file we see the field "Architectures", which doesn't include 'all' at the moment. With the idea outlined above that 'all' is a "proper" architecture now, we interpret this field as being authoritative in declaring which architectures are supported by this repository. If it says 'all', apt will try to get all, if not it will be skipped. This gives us another interesting feature: If I configure a source to download armel and mips, but it declares it supports only armel apt will now print a notice saying as much. Previously this was a very cryptic failure. If on the other hand the repository supports mips, too, but for some reason doesn't ship mips packages at the moment, this 'missing' file is silently ignored (= that is the same as the repository including an empty file). The Architectures field isn't mandatory through, so if it isn't there, we assume that every architecture is supported by this repository, which skips the arch:all if not listed in the release file. 2015-09-15T08:16:09Z David Kalnischkies david@kalnischkies.de 2015-09-14T22:33:12Z urn:sha1:6c0765c096ffb4df14169236c865bbb2b10974ae This allows running tests in parallel. Git-Dch: Ignore 2015-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-08T13:22:01Z urn:sha1:8d041b4f4f353079268039dcbfd8b5e575196b66 If we have a file on disk and the hashes are the same in the new Release file and the old one we have on disk we know that if we ask the server for the file, we will at best get an IMS hit – at worse the server doesn't support this and sends us the (unchanged) file and we have to run all our checks on it again for nothing. So, we can save ourselves (and the servers) some unneeded requests if we figure this out on our own. 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-05-13T14:09:12Z David Kalnischkies david@kalnischkies.de 2015-05-13T14:09:12Z urn:sha1:8eafc759544298211cd0bfaa3919afc0fadd47d1 Not all servers we are talking to support If-Modified-Since and some are not even sending Last-Modified for us, so in an effort to detect such hits we run a hashsum check on the 'old' compared to the 'new' file, we got the hashes for the 'new' already for "free" from the methods anyway and hence just need to calculated the old ones. This allows us to detect hits even with unsupported servers, which in turn means we benefit from all the new hit behavior also here.