apt/test, branch 2.5.3

Merge branch 'pu/phased-updates-fixes-2022-09-23' into 'main'

2022-09-28T15:13:12Z

phased update improvements See merge request apt-team/apt!262

full-upgrade: Mark phased upgrades for keep before anything else

2022-09-28T14:32:44Z

By marking them at the end, we might make other decisions that depend on the new phased updates, confusing the solver. Run the marking at the start too. The EDSP test file from Jeremy was modified to include Machine-ID and Phased-Update-Percentage fields and then filtered to mostly exclude packages irrelevant to the test case by running grep-dctrl \( -FRequest "EDSP 0.5" -o -FInstalled yes \ -oFPhased-Update-Percentage 10 \) \ -a --not -FArchitecture i386 LP: #1990586

Check state of dependency, not dependee in dependency keep back

2022-09-28T14:32:44Z

When iterating over I's dependencies (which are called Pkg), we accidentally checked if I was Protected() instead of Pkg when deciding whether Pkg can be kept back. LP: #1990684

Merge branch 'fix/install-pkg-order' into 'main'

2022-09-21T10:48:54Z

Respect users pkg order on `apt install` for resolving See merge request apt-team/apt!256

interactive-helper: Undefine _FORTIFY_SOURCE

2022-09-17T03:07:40Z

This ensures that it compiles when clang compiler is passing -DFORTIFY_SOURCES=2 Signed-off-by: Khem Raj

Respect users pkg order on `apt install` for resolving

2022-09-02T21:37:58Z

The command line is evaluated in two steps: First all packages given are marked for install and as a second step the resolver is started on all of them in turn to get their dependencies installed. This is done so a user can provide a non-default choice on the command line and have it respected regardless of where on the command line it appears. On the other hand, the order in which dependencies are resolved can matter, so instead of using a "random" order, we now do this in the order given on the command line, so if you e.g. have a meta package pulling in non-default choices and mention it first the choices are respected predictably instead of depending on first appearance of the package name while creating the binary cache. I might have "broken" this more than a decade ago while introducing the reworked command line parsing for Multi-Arch, which also brought in the split into the two steps mentioned above which was the far more impactful 'respect user choice' change. This one should hardly matter in practice, but as the tests show, order can have surprising side effects.

Add flag to disable upgrade by source and test case

2022-07-24T13:44:13Z

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.

Add test cases

2022-07-11T16:06:59Z

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