Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.0 2020-05-04T10:48:56Z 2020-05-04T10:48:56Z Julian Andres Klode julian.klode@canonical.com 2020-05-04T10:23:50Z urn:sha1:75f59b16312523ab3deb995c48e8c8ae07586c23 Reinstate * wildcards as they are safe to use, but do not allow any other special characters such as ? or []. Notably, ? would overlap with patterns, and [] might overlap with future pattern extensions (alternative bracketing style), it's also hard to explain. Closes: #953531 LP: #1872200 2020-04-27T11:51:46Z David Kalnischkies david@kalnischkies.de 2020-04-27T11:51:46Z urn:sha1:ae23e53f99ea0b7920744a7303fdee64796b7cce Strange things happen if while resolving the dependencies of a package said dependencies want to remove the package. The allow-scores test e.g. removed the preferred alternative in favor of the last one now that they were exclusive. In our or-group for Recommends we would "just" not statisfy the Recommends and for Depends we engage the ProblemResolver… 2020-04-27T11:49:43Z David Kalnischkies david@kalnischkies.de 2020-04-26T19:09:14Z urn:sha1:ca14e1e2c3f3c9782f374757ca4605ce7e5670ad In normal upgrade scenarios this is no problem as the orgroup member will be marked for upgrade already, but on a not fully upgraded system (or while you operate on a different target release) we would go with our usual "first come first serve" approach which might lead us to install another provider who comes earlier – bad if the providers conflict. 2020-04-27T11:49:19Z David Kalnischkies david@kalnischkies.de 2020-04-27T11:49:19Z urn:sha1:f76a8d331a81bc7b102bdd4e0f8363e8a59f64f6 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. 2020-04-27T11:48:33Z David Kalnischkies david@kalnischkies.de 2020-04-27T11:48:33Z urn:sha1:347ea3f76ab263c729468e07b910ae027b66c9d8 MarkDelete is not recursive as MarkInstall is and we can not conflict with ourselves anyhow, so we can move the unavoidable deletes before changing the state of the package in question avoiding the need for the state update in case of conflicts we can not deal with (e.g. the package conflicts with an explicit user request). 2020-04-27T11:47:08Z David Kalnischkies david@kalnischkies.de 2020-04-26T11:14:43Z urn:sha1:76498d46855c88b90316e4369ac32050db9a9d23 Should be easier to move the code bits around then and it helps in documenting a bit what the blocks do and how they interact (or not). 2020-04-27T11:45:59Z David Kalnischkies david@kalnischkies.de 2020-04-26T11:11:31Z urn:sha1:0de399391372450d0162b5a09bfca554b2d27c3d We do pretty much the same in IsInstallOk, but here we have already set the state, so we have to unroll the state as well to sort-of replicate the state we were in before this MarkInstall failed. 2020-04-27T11:45:41Z David Kalnischkies david@kalnischkies.de 2020-04-27T11:45:41Z urn:sha1:924704ba1dc13f73edb0db6c3c8c07ccf0ec26b6 This fixes no bugs per se, but the idea is to delay more costly changes and check easier things first. It e.g. inhibits the moving of the autobit until we are sure that this MarkInstall call isn't going to fail (e.g. because a dependency isn't satisfiable). 2020-04-27T11:44:24Z David Kalnischkies david@kalnischkies.de 2020-04-25T09:28:47Z urn:sha1:ff4555c72df967e40590d9e8c6ce83e9df4c46ea MarkInstall only looks at the first alternative in an or-group which has a fighting chance of being satisfiable (= the package itself satisfies the dependency, if it is installable itself is not considered). This is "hidden" for Depends by the problem resolver who will try another member of the or-group later, but Recommends are not a problem for it, so for them the alternatives are never further explored. Exploring the or-group in MarkInstall seems like the better choice for both types as that frees the problem resolver to deal with the hard things like package conflicts. 2020-04-26T16:35:34Z David Kalnischkies david@kalnischkies.de 2020-04-25T08:00:34Z urn:sha1:aa7d2f55a0b0d683fbcd46d2a80c99957b788c3a We reseted the candidate for installed packages back to the version which is installed if one of the (critical) dependencies of it is not statisfiable, but we can do the same for non-installed packages by discarding the candidate which beside slightly helping the resolver also improves error messages generated by apt as a sideeffect.