Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.4 2021-01-11T10:39:38Z 2021-01-11T10:39:38Z Julian Andres Klode julian.klode@canonical.com 2021-01-11T10:39:38Z urn:sha1:229e73afa4d6e862262f898a7e58942c90939306 We interpreted "cannot detect chroot" as "not a chroot", but it's arguably the better idea to detect it as a chroot, to avoid new behavior from phased updations in situations where it's unclear (no /proc mounted or stuff). 2021-01-08T17:02:10Z Julian Andres Klode julian.klode@canonical.com 2021-01-08T17:02:10Z urn:sha1:d43b1a03db9e17c69a15b2838fde69450764727a Gbp-Dch: ignore 2021-01-08T13:48:47Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T18:16:11Z urn:sha1:c5bc86d45e003905ef411146e66b414d26fb1ff8 This adds support for Phased-Update-Percentage by pinning upgrades that are not to be installed down to 1. The output of policy has been changed to add the level of phasing, and documentation has been improved to document how phased updates work. The patch detects if it is running in a chroot, and if so, always includes phased updates, restoring classic apt behavior to avoid behavioral changes on buildd chroots. Various options are added to control this all: * APT::Get::{Always,Never}-Include-Phased-Updates and their legacy update-manager equivalents to always or never include phased updates * APT::Machine-ID can be set to a UUID string to have all machines in a fleet phase the same * Dir::Etc::Machine-ID is weird in that it's default is sort of like ../machine-id, but not really, as ../machine-id would look up $PWD/../machine-id and not relative to Dir::Etc; but it allows you to override the path to machine-id (as opposed to the value) * Dir::Bin::ischroot is the path to the ischroot(1) binary which is used to detect whether we are running in a chroot. 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.