apt/apt-pkg/pkgcachegen.cc, branch 2.7.9

Compare SHA256 to check if versions are really the same

2023-08-02T10:04:32Z

If we know both SHA256, and they're different, the packages are. This approach stores the SHA256 only at runtime, avoiding the overhead of storing it on-disk, because when we update repositories we update all of them anyhow. Note that pkgCacheGenerator is hidden, so we can just modify its ABI, hooray. Closes: #931175 LP: #2029268

Do not make provides of M-A:allowed implicit M-A:foreign

2021-09-04T13:35:15Z

As we don't know which architectures we will deal with and to avoid creating many "unneeded" packages (and provides) the cache generation uses a scheme of on-demand creation (see ecc138f858). This assumed a particular handling of :any which got changed later (3addaba1ff) making this code path not only no longer needed for M-A:allowed, but actually wrong as it would go on and create provides for the explicit Provides of a package as if the package would be M-A:foreign. The result was that a package A:amd64 providing B tagged as M-A:allowed would satisfy a "C:armel depends on B". Note that this bug does NOT effect "C:armel depends on A" which is (correctly) not satisfied as before. References: ecc138f858, 3addaba1ff

Use size of the old cache as APT::Cache-Start default

2021-02-04T10:00:00Z

Depending on your configured source 25 MB is hardly enough, so the mmap housing the cache while it is build has to grow. Repeatedly. We can cut down on the repeats of this by keeping a record of the size of the old cache assuming the sizes will remain roughly in the same ballpark.

Avoid undefined pointer arithmetic while growing mmap

2021-02-04T10:00:00Z

The undefined behaviour sanitizer complains with: runtime error: addition of unsigned offset to 0x… overflowed to 0x… Compilers and runtime do the right thing in any case and it is a codepath that can (and ideally should) be avoided for speed reasons alone, but fixing it can't hurt (too much).

pkgcachegen: Avoid write to old cache for Version::Extra

2021-01-13T15:43:04Z

Assigning the result of AllocateInMap directly to Ver->d caused Ver->d to be resolved first, and hence if Ver was remapped during the AllocateInMap, we were trying to assign to the old value. Closes: #980037

Add support for Phased-Update-Percentage

2021-01-08T13:48:47Z

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.

apt-pkg: default visibility to hidden

2020-02-26T19:34:54Z

Silence narrow conversion warnings, add error checks

2020-02-25T10:27:30Z

When converting a long offset to a uint32_t to be stored in the map, check that this is safe to do. If the offset is negative, or we lose data in the conversion, we lost.

Make map_pointer typesafe

2020-02-24T17:29:07Z

Instead of just using uint32_t, which would allow you to assign e.g. a map_pointer to a map_pointer, use our own smarter struct that has strict type checking. We allow creating a map_pointer from a nullptr, and we allow comparing map_pointer to nullptr, which also deals with comparisons against 0 which are often used, as 0 will be implictly converted to nullptr.

Wrap AllocateInMap with a templated version

2020-02-24T17:09:49Z