apt/apt-pkg/depcache.cc, 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.

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

Use pkgTagSection::Key in more places in src:apt

2022-04-01T12:16:19Z

The speed critical paths were converted earlier, but the remaining could benefit a tiny bit from this as well especially as we have the facility now available and can therefore brush up the code in various places in the process as well. Also takes the time to add the hidden Exists method advertised in the headers, but previously not implemented.

Avoid using unqualified make_pair potentially triggering ftbfs

2022-03-21T01:57:34Z

If the includes are slightly changed, we end with an error here: apt/apt-pkg/depcache.cc:2059:31: error: ‘make_pair’ was not declared in this scope; did you mean ‘std::make_pair’? Yes, we mean std::make_pair, but we can avoid the explicit call altogether by using emplace_back instead of push_back.

Spelling fixes

2021-11-27T10:22:38Z

Do not remove Essential/Protected due to dependencies

2021-11-17T16:32:18Z

Suggesting the removal of Essential and Protected packages as a solution leads to situations where YouTubers end up removing their desktop. Let's not remove such packages ourselves.

Increase recursion limits from 100 to 3000

2021-08-29T12:23:26Z

If you install dpkg on an empty status file with all recommends and suggests apt wants to install 4000+ packages. The deepest chain seemingly being 236 steps long. And dpkg isn't even the worst (~259). That is a problem as libapt has a hardcoded recursion limit for MarkInstall and friends … set to 100. We are saved by the fact that chains without suggests are much shorter (dpkg has 5, max seems ~43), but I ignored Conflicts in these chains, which typically trigger upgrades, so if two of the worst are chained together we suddenly get dangerously close to the limit still. So, lets just increase the limit into oblivion as it is really just a safety measure we should not be running into to begin with. MarkPackage was running years without it after all. 3000 is picked as a nice number as any other and because it is roughly the half of the stack crashs I saw previously in this branch.

Stop autoremover from endlessly exploring cyclic providers

2021-08-28T20:21:35Z

fullyExplored is needed to keep track of having explored all providers of a package name, while Marked is tracking if we have explored a given real package (along its chosen version), so we should stop MarkPackage from exploring a (real) package if it is marked and let fullyExplored only guard the looping over the individual dependencies. The testcase is deceptively simple, but in practice only an ecosystem like rust who makes heavy use of cyclic dependency relations intermixed with versioned provides actually triggers this as seen by the buggy code being in use for four months in Debian and Ubuntu development releases. (easier to trigger if most packages are marked manual installed) Note that the testcase is successful already due to the earlier changes as we exit the recursion eventually and all packages are marked as they need to be already, but this fix does work standalone as well. Closes: #992993