Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2_exp1 2016-01-08T20:20:25Z 2016-01-08T20:20:25Z Julian Andres Klode jak@debian.org 2016-01-08T10:12:14Z urn:sha1:60d523e2ae93a6c5bc396b6bede2544271fb1f2e By storing the size of the string in the cache, we can make use of it when comparing the names in the hashtable in pkgCache::FindGrp. 2016-01-08T20:20:25Z Julian Andres Klode jak@debian.org 2016-01-08T20:19:32Z urn:sha1:af4899c9df6e925b1cb099c29bd78788b2984cca Hide the std::string overload instead of providing a const char * one, the old variant was stupid. Gbp-Dch: ignore 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-08T16:51:23Z David Kalnischkies david@kalnischkies.de 2016-01-08T16:51:23Z urn:sha1:ef3c549e00b2a0487ddee0aeb70e3a29f76c2fbb The code already deals with compressed leftovers, but forgot the uncompressed files. The opertunity is picked to reorder this code and add debug messages about the actions taken as well as produce such a leftover file in the associated testcase. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-08T14:30:05Z urn:sha1:4e6219da0dd1e68fad7db972f7ddd76598645228 With the addition of the $HASH-Download field in the .diff/Index we got the size of the compressed patches for 'free', so if that information is available we can use it for a more fitting calculation of the size requirements of the patches vs. the complete file. Note that this predicts a too small size in the transition case in which the information isn't available for all patches, but figuring this out would be a lot of code for practically nothing as only one update can ever be in such a transition phase. 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. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-05T23:08:04Z urn:sha1:1866240123a57de8f693b0ba01d8b709f027282d If we store files compressed in lists/ and the file switched compression formats we happened to retain the "old" format, but by default the cleanup process catched this oversight and removed the file. [The initial situation described doesn't arise as we store no files by default compressed and even with apt-file configuring Contents files, we don't really have that problem as there is just .gz files for those.] We solve this by just removing any uncompressed as well as compressed (we support) file just before we move the 'new' version of the file in. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-03T18:23:30Z urn:sha1:9bd2313a5c7523501bcec398877489c5a1fc1415 Adding a new compressor method meant adding a new method as well – even if that boilt down to just linking to our generalized decompressor with a new name. That is unneeded busywork if we can instead just call the generalized decompressor and let it figure out which compressor to use based on the filenames rather than by program name. For compatibility we ship still 'gzip', 'bzip2' and co, but they are just links to our "new" 'store' method. 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.