Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta2 2016-06-22T12:05:01Z 2016-06-22T12:05:01Z David Kalnischkies david@kalnischkies.de 2016-06-20T18:50:43Z urn:sha1:d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a Weak had no dedicated option before and Insecure and Downgrade were both global options, which given the effect they all have on security is rather bad. Setting them for individual repositories only isn't great but at least slightly better and also more consistent with other settings for repositories. 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-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. 2015-11-27T14:40:47Z David Kalnischkies david@kalnischkies.de 2015-11-27T14:40:47Z urn:sha1:5dd00edbcf702cac1ea22392796c65881a8ef6f9 Git-Dch: Ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T20:08:55Z urn:sha1:258b9e512c4001e806c5c0966acecd3d742ec6e9 Reported-By: cppcheck Git-Dch: Ignore 2015-09-14T13:22:19Z David Kalnischkies david@kalnischkies.de 2015-09-14T11:18:29Z urn:sha1:24e8f24e1e94ec3816b0bfc7a05d1c4e3f73248e This changes the semantics of the option (which is renamed too) to be a yes/no value with the special additional value "force" as this allows by-hash to be disabled even if the repository indicates it would be supported and is more in line with our other yes/no options like pdiff which disable themselves if no support can be detected. The feature wasn't documented so far and hasn't reached a (un)stable release yet, so changing it without trying too hard to keep compatibility seems okay. 2015-08-30T20:50:55Z David Kalnischkies david@kalnischkies.de 2015-08-30T20:34:28Z urn:sha1:3090ae6972fd0e15767a96708c248f3ab87502f2 Multiple targets downloading the same file is bad™ as it leads us to all sorts of problems like the acquire system breaking or simply a problem of which settings to use for them. Beside that this is most likely a mistake and silently ignoring it doesn't help the user realizing his mistake… On the other hand, we have 'duplicates' which are 'created' by how we create indextargets, so we have to prevent those from being created to but do not emit a warning for them as this is an implementation detail. And then, there is the absolute and most likely user mistake: Having the same target(s) activated in multiple entries. 2015-08-29T16:59:40Z David Kalnischkies david@kalnischkies.de 2015-08-29T11:50:22Z urn:sha1:9adb9778d11db138d645e037e092db1fb64b5d4a Some targets like Contents-udeb are special-needs targets. Shipping the configuration snippet for them is okay, but they shouldn't be downloaded by default. Forcing the user to enable targets by uncommenting targets is wrong and this would still not really solve the problem completely as even if you want to download some -udebs it will probably not be for all sources you have enabled, so having the possibility of disabling a target by default, but giving the user the option to enable it on a per-source entry basis is better. 2015-08-28T17:26:44Z David Kalnischkies david@kalnischkies.de 2015-08-28T17:26:44Z urn:sha1:d7a51997c30b2098bb60b3397095ec58ec825303 Some additional files like 'Contents' are very big and should therefore kept compressed on the disk, which apt-file did in the past. It also implemented pdiff patching of these files by un- and recompressing these files on-the-fly, with this commit we can do the same – but we can do this in both pdiff patching styles (client and server merging) and secured by hashes. Hashes are in so far slightly complicated as we can't compare the hashes of the compressed files as we might compress them differently than the server would (different compressor versions, options, …), so we must compare the hashes of the uncompressed content. While this commit has changes in public headers, the classes it changes are marked as hidden, so nobody can use them directly, which means the ABI break is internal only.