Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4 2016-07-05T18:45:47Z 2016-07-05T18:45:47Z David Kalnischkies david@kalnischkies.de 2016-07-05T18:36:15Z urn:sha1:68151307d42ed64cd6258f94a0d748abe9efb8e0 The test makes heavy use of disabling compression types which are usually available some way or another like xz which is how the EIPP logs are compressed by default. Instead of changing this test to change the filename according to the compression we want to test we just disable EIPP logging for this test as that is easier and has the same practical effect. Gbp-Dch: Ignore 2016-06-10T08:48:25Z David Kalnischkies david@kalnischkies.de 2016-06-09T18:41:58Z urn:sha1:bdc42211700ef0f6f40e4ef3f362e52d684d70fb This effects only compressors configured on the fly (rather then the inbuilt ones as they use a library). 2016-05-16T14:17:54Z David Kalnischkies david@kalnischkies.de 2016-05-14T08:43:03Z urn:sha1:eb1f04dda07c2b69549ad9fd793cca0e91841b3e This commit moves the creation of the fetcher and with it the calculation of the filenames before the code generation the various lists detailing the solution. This means that simulation comes even so slightly closer to a real run as it will require and parse the package indexes for filenames and queuing of URIs, so that a simulation "using" an unavailable download method actually fails now. The real benefit of this change is through that the rather special but nontheless handy --no-download --fix-missing mode now actually shows what the solution is it will apply to the system rather than the solution it would if it could download all not-downloaded packages. 2016-04-14T19:56:01Z David Kalnischkies david@kalnischkies.de 2016-04-14T15:32:17Z urn:sha1:b2fd852459a6b9234255644730f48f071ccad64d There is just no point in taking the time to acquire empty files – especially as it will be tiny non-empty compressed files usually. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-07T19:32:09Z urn:sha1:0179cfa83cf0042235eda41db7f35c420781c63e Downloading and storing are two different operations were different compression types can be preferred. For downloading we provide the choice via Acquire::CompressionTypes::Order as there is a choice to be made between download size and speed – and limited by whats available in the repository. Storage on the other hand has all compressions currently supported by apt available and to reduce runtime of tools accessing these files the compression type should be a low-cost format in terms of decompression. apt traditionally stores its indexes uncompressed on disk, but has options to keep them compressed. Now that apt downloads additional files we also deal with files which simply can't be stored uncompressed as they are just too big (like Contents for apt-file). Traditionally they are downloaded in a low-cost format (gz) as repositories do not provide other formats, but there might be even lower-cost formats and for download we could introduce higher-cost in the repositories. Downloading an entire index potentially requires recompression to another format, so an update takes potentially longer – but big files are usually updated via pdiffs which has to de- and re-compress anyhow and does it on the fly anyhow, so there is no extra time needed and in general it seems to be benefitial to invest the time in update to save time later on file access. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-03T21:39:46Z urn:sha1:912a61312a0463b46d6560756c89146f59daaab6 Less hardcoding should help while introducing new compressors. Git-Dch: Ignore 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-11-04T17:04:00Z David Kalnischkies david@kalnischkies.de 2015-10-11T11:58:23Z urn:sha1:af9e40c9bfb353b8aea1e2621b3b5a8c1c1db4bd Commit 653ef26c70dc9c0e2cbfdd4e79117876bb63e87d broke the camels back in sofar that everything works in terms of our internal use of copy:/, but external use is completely destroyed. This is kinda the reverse of what happened in "parallel" in the sid branch, where external use was mostly fine, internal and external exploded on the GzipIndexes option. We fix this now by rewriting our internal use by letting copy:/ only do what the name suggests it does: Copy files and not uncompress them on-the-fly. Then we teach copy and the uncompressors how to deal with /dev/null and use it as destination file in case we don't want to store the uncompressed files on disk. Closes: 799158 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-30T08:53:51Z urn:sha1:653ef26c70dc9c0e2cbfdd4e79117876bb63e87d There is an option to keep all targets (Packages, Sources, …) compressed for a while now, but the all-or-nothing approach is a bit limited for our purposes with additional targets as some of them are very big (Contents) and rarely used in comparison, so keeping them compressed by default can make sense, while others are still unpacked. Most interesting is the copy-change maybe: Copy is used by the acquire system as an uncompressor and it is hence expected that it returns the hashes for the "output", not the input. Now, in the case of keeping a file compressed, the output is never written to disk, but generated in memory and we should still validated it, so for compressed files copy is expected to return the hashes of the uncompressed file. We used to use the config option to enable on-the-fly decompress in the method, but in reality copy is never used in a way where it shouldn't decompress a compressed file to get its hashes, so we can save us the trouble of sending this information to the method and just do it always.