Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.11 2018-03-12T07:56:59Z 2018-03-12T07:56:59Z Julian Andres Klode julian.klode@canonical.com 2018-03-08T08:33:39Z urn:sha1:4de4200ec2717e777bbf99ed82d1b4344f078ec2 zstd is a compression algorithm developed by facebook. At level 19, it is about 6% worse in size than xz -6, but decompression is multiple times faster, saving about 40% install time, especially with eatmydata on cloud instances. 2017-09-09T15:22:00Z David Kalnischkies david@kalnischkies.de 2017-08-14T08:36:55Z urn:sha1:cba5c5a26a9bf00724f8ea647ac61b30e32734ba A libapt user who hasn't initialized _system likely has a reason, so we shouldn't greet back with a segfault usually deep down in the callstack for no reason. If the user had intended to pick up information from the system, _system wouldn't be uninitialized after all. LP: #1613184 SRU: 1.4.y 2017-07-12T11:57:51Z Julian Andres Klode jak@debian.org 2017-07-12T11:40:41Z urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3 This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh. 2016-07-05T18:44:45Z David Kalnischkies david@kalnischkies.de 2016-07-05T12:46:39Z urn:sha1:29b8e6b939bb7fcf0b2959545d8c822995c84118 This is in so far pointless as the first match will deal with the extension, so we don't actually ever use these second instances – probably for the better as most need arguments to behave as epected & more importantly: the point of the exercise disabling their use for testing proposes. Gbp-Dch: Ignore 2016-06-14T12:32:14Z David Kalnischkies david@kalnischkies.de 2016-06-14T12:32:14Z urn:sha1:90f2a7a0f66cfc259883490a5fcf40f7d0696cfe We usually use absolute paths to specific the location of dpkg, apt-key and the like, but there is nothing wrong with using just the command name and instead let exec(3) make the lookup in PATH. We had a wild mixture before, so opting for the more accepting option out of the two seems about right especially as it makes no difference in the default case as apt uses absolute paths. 2016-05-27T12:08:44Z David Kalnischkies david@kalnischkies.de 2016-05-27T10:08:32Z urn:sha1:124e6916b7b02984803ff8217e8163947aae2882 libapt allows to configure compressors to be used by its system via configuration implemented in 03bef78461c6f443187b60799402624326843396, but that was never really documented and also only partly working, which also explains why the tests weren't using it… 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-07T13:28:27Z Julian Andres Klode jak@debian.org 2015-12-27T23:07:03Z urn:sha1:e3fbd54cee3fffecbf4f7c384e0aad715fc68218 Implement native support for LZ4 compression, using the official lz4 library. 2016-01-03T13:53:26Z Julian Andres Klode jak@debian.org 2016-01-03T13:53:26Z urn:sha1:59f1f42b7507137a10e1dae0636cd3a020a06a0e This will give us the freedom to insert more compressors at positions in between. Also change the cost of uncompressed to 0, as that really has no overhead, and the values do not really mean much. 2015-12-28T20:50:13Z Julian Andres Klode jak@debian.org 2015-12-28T20:50:13Z urn:sha1:1a3296c0bd67c46c6ff791345b6101edcb97e778 Since commit 7a68effcb904b4424b54a30e448b6f2560cd1078, the xz and lzma compressors read the level of compression they shall use. A default of -9 is too much for them, this will use 674 MB, according to the xz manual page. Level -6 on the other hand only needs 94 MB memory for compression. This causes autopkgtest failures in the test-compressed-indexes test, as not enough memory exists to proceed. Change the other compression levels to 6 as well: The gzip and bzip2 FileFd backends do not read them, and use their code's default level which is 6, so do the same for external methods.