apt/test/integration/test-multiarch-allowed, branch 2.9.22

test: Support the 3.0 solver in most existing test cases

2024-05-24T15:01:35Z

Highlights: - test-bug-618848-always-respect-user-requests: (Do not) Support 3.0 solver A manually installed package is never removed just because we request the removal of its dependency in solver3. - test-bug-657695-resolver-breaks-on-virtuals: Support 3.0 solver For manually installed packages, solver 3.0 would require some new xserver-xorg-video-driver to Conflict+Replace+Provides the old one (once the logic is implemented), but that does seem reasonable. - test-bug-720597-build-dep-purge: Support 3.0 solver This needs a simple aptmark auto because pkga is removed by the build-dep. But further adjustments are necessary because it weirdly tested for no autoremovable packages before installing pkgc. - test-bug-960705-*: Support 3.0 solver Bit awkward to deal with; notably the protect to conflict doesn't actually work anymore and that is a feature these days.

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.

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

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

Ensure dpkg -C works correctly in our testcases

2021-09-04T13:35:15Z

Gbp-Dch: Ignore

Recognize propagated protected in pkgProblemResolver

2020-05-18T13:55:36Z

Turns out that pkgDepCache and pkgProblemResolver maintain two (semi) independent sets of protected flags – except that a package if marked protected in the pkgProblemResolver is automatically also marked in the pkgDepCache as protected. This way the pkgProblemResolver will have as protected only the direct user requests while pkgDepCache will (hopefully) propagate the flag to unavoidable dependencies of these requests nowadays. The pkgProblemResolver was only checking his own protected flag though and based on that calls our Mark* methods usually without checking return, leading to it believing it could e.g. remove packages it actually can't remove as pkgDepCache will not allow it as it is marked as protected there. Teaching it to check for the flag in the pkgDepCache instead avoids it believing in the wrong things eventually giving up. The scoring is keeping the behaviour of adding the large score boost only for the direct user requests though as there is no telling which other sideeffects this might have if too many packages get too many points from the get-go. Second part of fixing #960705, now with pkgProblemResolver output which looks more like the whole class of problem is resolved rather than a teeny tiny edgecase it was before.

Keep going if a dep is bad for user requests to improve errors

2020-05-18T13:55:36Z

We exit early from installing dependencies of a package only if it is not a user request to avoid polluting the state with installs which might not be needed (or detrimental even) for alternative choices. We do continue with installing dependencies though if it is a user request as it will improve error reporting for apt and can even help aptitude not hang itself so much as we trim the problem space down for its resolver dealing with all the easy things. Similar things can be said about the testcase I have short-circuit previously… keep going test, do what you should do to report errors!

Propagate Protected flag to single-option dependencies

2020-04-27T11:49:19Z

If a package is protected and has a dependency satisfied only by a single package (or conflicts with a package) this package must be part of the solution and so we can help later actions not exploring dead ends by propagating the protected flag to these "pseudo-protected" packages. An (obscure) bug this can help prevent (to some extend) is shown in test-apt-never-markauto-sections by not causing irreversible autobit transfers. As a sideeffect it seems also to help our crude ShowBroken to display slightly more helpful messages involving the packages which are actually in conflict.

fix M-A:foreign provides creation for unknown archs

2016-01-14T22:08:02Z

Architectures for packages which do not belong to the native nor a foreign architecture (dubbed barbarian for now) which are marked M-A:foreign still provide in their own architecture even if not for others. Also, other M-A:foreign (and allowed) packages provide in these barbarian architectures.

tests: support spaces in path and TMPDIR

2015-12-19T22:04:34Z

This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore