Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.0 2020-05-04T14:02:21Z 2020-05-04T14:02:21Z Julian Andres Klode julian.klode@canonical.com 2020-05-04T14:02:21Z urn:sha1:e14e69b62720db780f2438c1fffcde4a3820cd96 2020-05-04T14:01:43Z Julian Andres Klode julian.klode@canonical.com 2020-05-04T14:01:43Z urn:sha1:1cf66604dc70c21fd58c6779868720288017d6e7 We did not merge nl with the template when we updated it, hence we have quite a bit of churn in that commit and this one. 2020-05-04T12:10:50Z Julian Andres Klode jak@debian.org 2020-05-04T12:10:50Z urn:sha1:2265697c83faa308408cbf7d78b10317228ebad6 Reinstate * wildcards See merge request apt-team/apt!118 2020-05-04T11:08:33Z Julian Andres Klode julian.klode@canonical.com 2020-05-04T11:08:33Z urn:sha1:c4f85bcb8bee1b5e647c7e629f616cffc7d12bbc Previously (and still in cacheset), patterns where only allowed to start with ? or ~, which ignores the fact that a pattern might just as well start with a negation, such a !~nfoo. Also, we ignored the --regex flag if it looked like this, which was somewhat bad. Let's change this all: * If --regex is given, arguments are always interpreted as regex * If it is a valid package wildcard (name or * characters), then it will be interpreted as a wildcard - this set of characters is free from meaningful overlap with patterns. * Otherwise, the argument is interpreted as a pattern. For a future version, we need to adapt parsing for cacheset and list to use a common parser, to avoid differences in their interpretation. Likely, this code will go into the pattern parser, such that it generates a pattern given a valid fnmatch argument for example. 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-05-04T09:28:11Z Julian Andres Klode jak@debian.org 2020-05-04T09:28:11Z urn:sha1:6e6a9331e6d27d371844ec98775619328526f33d Refactor MarkInstall fixing various or-group handling issues See merge request apt-team/apt!117 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).