apt/apt-pkg, branch 2.5.2

Add flag to disable upgrade by source and test case

2022-07-24T13:44:13Z

Avoid recursion by looping of other binaries twice

2022-07-24T13:27:18Z

First mark them for upgrade without autoInst, so we don't call their "mark other binaries loop"; then call them again with it. Without this change, each binary package would upgrade the next one in the list, recursively.

Upgrade all binaries in a source package

2022-07-24T13:27:18Z

Schedule all other binaries in the source package for upgrade if the candidate version belongs to the same source version as the package we are upgrading. This will significantly reduce the risk of partial upgrades and should make life a lot easier.

Merge branch 'pu/upgrade-broken-depends' into 'main'

2022-07-24T13:05:48Z

Mark broken reverse depends for upgrade See merge request apt-team/apt!248

apt-pkg: (re)export pkgTagSection::Key to fix FTBFS in python-apt

2022-07-22T12:49:45Z

With apt 2.5.1 python-apt fails to build with: ``` ... x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.10 -c python/acquire-item.cc -o build/temp.linux-x86_64-3.10/python/acquire-item.o -std=c++11 -Wno-write-strings -DAPT_8_CLEANER_HEADERS -DAPT_9_CLEANER_HEADERS -DAPT_10_CLEANER_HEADERS -DPY_SSIZE_T_CLEAN In file included from python/python-apt.h:30, from python/apt_pkgmodule.h:211, from python/acquire-item.cc:25: /usr/include/apt-pkg/deblistparser.h:48:65: error: ‘pkgTagSection::Key’ has not been declared 48 | bool ParseDepends(pkgCache::VerIterator &Ver, pkgTagSection::Key Key, | ^~~ ``` This commit adds a small fix by (re)exporting `pkgTagSection::Key`.

Mark broken reverse depends for upgrade

2022-07-11T14:37:33Z

Currently the solver handles cases where a Breaks b (<< 1) and if we install that a, upgrades b. However, where b Depends a (= 1), b was removed again. This addresses the problem by iterating over installed reverse dependencies of upgrades and upgrading them so that both cases work roughly similarly. LP: #1974196

Merge branch 'pu/phasing-better' into 'main'

2022-06-29T13:30:03Z

Rewrite phased updates using a keep-back approach See merge request apt-team/apt!245

policy: Do not override negative pins with 1 due to phasing

2022-06-28T12:54:42Z

If a package is already pinned to a negative value, we should not override this with a positive 1. This causes packages to be installable that were pinned to -1, which is not intended. For this, implement phasing as a ceiling of 1 for the pin instead of a fixed 1 value. An alternative would have been to fix it to NEVER_PIN, but that would mean entirely NEW packages would not be installable while phasing which is not the intention either. LP: #1978125

(Temporarily) Rewrite phased updates using a keep-back approach

2022-06-28T12:25:18Z

This is a lot closer to the original implementation in update-manager, but still has a couple of differences that might cause bugs: - When checking whether a version is a security update, we only check versions in between and not any later version. This happens mostly because we do not know the suite, so we just check if there is any version between the installed version and our target that is a security update - We only keep already installed packages, as we run before the resolver. update-manager first runs the resolver, and then marks for keep all packages that were upgraded or newly installed that are phasing (afaict). This approach has a significant caveat that if you have version 1 installed from a release pocket, version 2 is in security, and version 3 is phasing in updates, that it installs version 3 rather than 2 from security as the policy based implementation does. It also means that apt install does not respect phasing and would always install version 3 in such a scenario. LP: #1979244

Fix integer underflow in flExtension

2022-05-23T08:09:31Z

Before this patch, the expression `Res - File.length()` that was used as the length underflowed. It was very unlikely to cause any problem given the saturating behavior of the std::string constructor that's used. Replacing `Res - File.length()` with `File.length() - Res` would have worked, but omitting the last argument altogether invokes an std::string constructor which does the right thing.