Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.6 2020-06-03T11:41:14Z 2020-06-03T11:41:14Z David Kalnischkies david@kalnischkies.de 2020-06-03T11:03:37Z urn:sha1:96359a576f59eb8bc461bdd4c5eadeb17fe8f0ca While we process the possible solutions we might modify other solutions like discarding their candidates and such, so that then we reach them they might no longer be proper candidates. We also try to drop duplicates early on to avoid the simple cases of these which test-explore-or-groups-in-markinstall triggers via its explicit duplication but could also come via multiple provides. It only worked previously as were ignoring current versions which usually is okay expect if they are marked for removal and we want to reinstate them so the ProblemResolver can decide which one later on. 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-23T15:15:32Z urn:sha1:c77566fd8f21a1a44efb4092c90996d1cc8eaf24 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-23T14:55:59Z urn:sha1:0e5a9bf95d5b9b3c775ed3ce6142d35815a7c7ac Gbp-Dch: Ignore 2020-05-24T19:02:35Z David Kalnischkies david@kalnischkies.de 2020-05-23T14:22:44Z urn:sha1:2ba86f95bfad4ec00a3b99b311d05c158162b25c For speed reasons pkgDepCache initializes its state once and then has a battery of update calls you have to invoke in the right order to update the various states – all in the name of speed. In debug and/or simulation mode we can sacrifice this speed for a bit of extra checking though to verify that we haven't made some critical mistake like #961266. 2020-05-23T15:59:19Z David Kalnischkies david@kalnischkies.de 2020-05-23T13:53:06Z urn:sha1:4f71dc657c34915508a9e34b000e1b577931655a It looks like hack and therefore I wanted this to be a very isolated commit so we can find it & revert it easily if need be, but for now it seems to work. The idea is that Status is telling us how the candidate is in relation to the current installed version which is used to figure out if a package is "kept back" by the algorithm or not, but by discarding the candidate version we loose this information. Ideally we would keep better tabs on what we do to a package and why, but for now that seems okayish. It will cause the wrong version to be displayed though as if the package is installed the installed version becomes the candidate and hence (installed => installed) is displayed. 2020-05-23T15:58:42Z David Kalnischkies david@kalnischkies.de 2020-05-22T17:52:26Z urn:sha1:4d87856b94dae1a40a1a8147a6dbcfe714cd05c7 If we have a negative dependency to deal with we prefer to install an upgrade rather than remove the current version. That is why we split the method rather explicitly in two in 57df273 but there is a case we didn't react to: If we have seen the candidate before as a "satisfier" of this negative dependency there is no point in trying to upgrade to it later on. We keep that info by candidate discard if we can, but even if we can't we can at least keep that info around locally. This "fixes" (or would hide) the problem described in 04a020d as well as you don't have to discard installations you never make. 2020-05-23T15:58:42Z David Kalnischkies david@kalnischkies.de 2020-05-22T16:56:40Z urn:sha1:04a020d7a217d6b5af86c048c2974760053b8079 For a (partially) installed package like the one MarkInstall operates on at the moment we want to discard the candidate from, we have to first remove the package from the internal state keeping to have proper broken counts and such and only then reset the candidate version which is a trivial operation in comparison. Take a look at the testcase: Now, what is the problem? Correct, git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries to switch the architecture of git here (which is pointless, it knows that this won't work, but lets fix that in another commit) will eventually realize that it can't install it and wants to discard the candidate of git:i386 first removing the broken indication like it should, removing the install flag and then reapplies the broken indication: Expect it doesn't as it wants to do that over the candidate version which the package no longer had so seemingly nothing is broken. It is a bit of a hairball to figure out which commit it is exactly that is wrong here as they are all influencing each other a bit, but >= 2.1 is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie. Closes: #961266 2020-05-18T13:55:36Z David Kalnischkies david@kalnischkies.de 2020-05-16T12:46:05Z urn:sha1:dbed89f296106f82e9fe8f866fa87a4c14b44584 The previous commit deals with negative, now we add the positive side of things as well which makes this a recursive endevour. As we can push the protected flag forward only if a single solution for a dependency exists it is easy for trees to not get it, so if resolving becomes difficult it won't help at all. 2020-05-18T13:55:36Z David Kalnischkies david@kalnischkies.de 2020-05-16T09:17:21Z urn:sha1:57df27397b1a10e50d5876482a30b9dedb2ad219 If we propagate protected e.g. due to a user request we should also act upon (at the moment) satisfied negative dependencies so that the resolver knows that installing this package later is not an option. That the problem resolver is trying bad solutions is a bug by itself which existed before and after and should be worked on. Closes: #960705 2020-05-18T13:55:36Z David Kalnischkies david@kalnischkies.de 2020-05-17T17:47:29Z urn:sha1:55d4d1b51c0d2b78b76f2b233714ed3914b695cf For positive dependencies this isn't giving much as the dependency should already be satisfied by such a provider if its protectiveness would help, but it doesn't hurt to check them first and for negative dependencies it means that we check those first which are the most likely to fail to be removed – which is a good idea.