Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2 2016-01-15T17:19:16Z 2016-01-15T17:19:16Z David Kalnischkies david@kalnischkies.de 2016-01-15T16:54:43Z urn:sha1:3b4045fc31baf3aa580bd695695d579c30a481b8 Git-Dch: Ignore 2016-01-14T22:08:02Z David Kalnischkies david@kalnischkies.de 2016-01-14T19:13:16Z urn:sha1:62428dbc17ffa7b5b8188e88609a9438428d6024 Architectures for packages which do not belong to the native nor a foreign architecture (dubbed barbarian for now) which are marked M-A:foreign still provide in their own architecture even if not for others. Also, other M-A:foreign (and allowed) packages provide in these barbarian architectures. 2016-01-08T20:08:51Z Julian Andres Klode jak@debian.org 2016-01-08T19:57:23Z urn:sha1:e9a1e5f9a37b8ddcdb98f2a0608f262e0863673a I overlooked this 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-08T11:37:58Z Julian Andres Klode jak@debian.org 2016-01-08T11:37:58Z urn:sha1:4a666d28d7f30f2eb856ffef0ea0343be6cccef1 Do not create strings within the loop, that creates one string per language and does more work than needed. Instead, reserve enough space at the beginning and assign the prefix, and then resize and append inside the loop. Also call exists with the string itself instead of the c_str(), this means that the lookup uses the size information in the string now and does not have to call strlen() on it. 2016-01-07T23:52:29Z Julian Andres Klode jak@debian.org 2016-01-07T23:52:29Z urn:sha1:57590d3c6e6b055402c938c3baebf1d872c58f7e This improves performance, as we now can ignore unequal strings based on their length already. Gbp-Dch: ignore 2016-01-07T18:59:08Z Julian Andres Klode jak@debian.org 2016-01-07T18:16:23Z urn:sha1:eff0c22e59e65b6b63e854ff41eb091278e05714 This improves performance of the cache generation on my ARM platform (4x Cortex A15) by about 10% to 20% from 2.35-2.50 to 2.1 seconds. 2016-01-02T15:19:40Z David Kalnischkies david@kalnischkies.de 2016-01-02T12:19:32Z urn:sha1:e21ba62847687b5dc655b28ef7dd67d6eb7336e2 Now (55153bf94ff28a23318e79aa48242244c4d82b3c) that pkgTagFile can be told to deal with all sorts of comments we can use this mode to parse dsc (as by catch) and debian/control files properly even in the wake of multiline fields spliced with comments like Build-Depends. Closes: 806775 2015-12-27T16:04:33Z David Kalnischkies david@kalnischkies.de 2015-12-27T16:04:33Z urn:sha1:a628ca5256b4a2f3ae300697b17adf150b6e17b0 Debian has a Packages file for arch:all already, but the arch:any files contain arch:all packages as well, so downloading it would be a total waste of resources. Getting this solved is on the list of things to do, but it is also the hardest part – for index targets like Contents the situation is much easier and less server/client implementations are involved so we might not want to stall them. A repository can now declare via: No-Support-for-Architecture-all: Packages that even if an arch:all Packages exists, it shouldn't be downloaded, so that support for Contents files can be added now. See also 1dd20368486820efb6ef4476ad739e967174bec4 for the implementation of downloading arch:all index targets, which this is limiting. The field uses the name of the target from the apt configuration for simplicity and is negative by design as this field is intended to be supported/needed only for a "short" time (one or two Debian releases). While this commit theoretically supports any target, its expected to only see "Packages" as a value in reality. 2015-12-27T10:50:05Z Julian Andres Klode jak@debian.org 2015-12-27T10:50:05Z urn:sha1:147041626609e95700781bea045f8e8ea18370a3 We do not see those branches at all during normal mode of operation (that is, during cache generation), so tell the compiler about it.