Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.7 2020-07-02T16:57:11Z 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:58:35Z urn:sha1:cfd0172fb0eeb15b2e2427c0e11b2ec65f501839 If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:14:33Z urn:sha1:3e39efa31da463ca05016513835d9a5388f80f90 Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically. 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.