Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=master 2018-08-29T15:50:31Z 2018-08-29T15:50:31Z David Kalnischkies david@kalnischkies.de 2018-08-22T07:54:07Z urn:sha1:55585d0f93de1a0e60858e594b1b3b46f4a0831f cppcheck reports: (error) Iterator 't' used after element has been erased. The loop is actually fashioned to deal with this (not in the most efficient way, but in simplest and speed isn't really a concern here) IF this codepath had a "break" at the end… so I added one. Note that the tests aren't failing before (and hopefully after) the change as the undefined behavior we encounter is too stable. Thanks: David Binderman for reporting 2016-05-08T16:15:28Z David Kalnischkies david@kalnischkies.de 2016-05-08T16:03:48Z urn:sha1:39c724b4848ef8d85c8c425f982dda85f0df1277 A frontend like apt-file is only interested in a specific set of files and selects those easily via "Created-By". If it supports two locations for those files through it would need to select both and a user would need to know that implementation detail for sources.list configuration. The "Identifier" field is hence introduced which by default has the same value as "Created-By", but can be freely configured – especially it can be used to give two indexes the same identifier. 2016-05-08T11:39:32Z David Kalnischkies david@kalnischkies.de 2016-05-08T09:58:36Z urn:sha1:7f2d1eef183dbebaaabe07a296d9a97e9cfd0f4a Sometimes index files are in different locations in a repository as it is currently the case for Contents files which are per-component in Debian, but aren't in Ubuntu. This has historic reasons and is perhaps changed soon, but such cases of transitions can always happen in the future again, so we should prepare: Introduced is a new field declaring that the current item should only be downloaded if the mentioned item wasn't allowing for transitions without a flagday in clients and archives. This isn't implemented 'simpler' with multiple MetaKeys as items (could) change their descriptions and perhaps also other configuration bits with their location. 2016-05-07T14:45:35Z David Kalnischkies david@kalnischkies.de 2016-05-07T14:45:35Z urn:sha1:7c1dca1439b956a085b09c73fdbe5a66af20241b It looks a bit strange on the outside to have multiple "native architecture", but all is considered an implementation detail and e.g. packages of arch:all are in dependency resolution equal to native 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-12T22:59:35Z Julian Andres Klode jak@debian.org 2016-01-12T22:45:59Z urn:sha1:7d2794a20bdab9b848bf5b4e88d73527405bad54 This prevents a test suite failure on systems with weird umasks. Also set umask 000 at the beginning so we can actually check for that anywhere. Gbp-Dch: ignore 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-05T23:05:24Z urn:sha1:4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e There is no reason to enforce that the file we start the bootstrap with is compressed with a compressor which is available online. This allows us to change the on-disk format as well as deals with repositories adding/removing support for a specific compressor. 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:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T15:02:44Z urn:sha1:cd46d4ebd33e74ee53bbc73dcdb7fe1d4d006558 The wrapping will fail in the best case and actually end up deleting /dev/null in the worst case. Given that there is no point in trying to write atomically to /dev/null as you can't read from it again just ignore these flags if higher level code ends up trying to use them on /dev/null. Git-Dch: Ignore