Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.0 2020-05-04T11:08:33Z 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-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: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: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. 2020-04-06T08:04:49Z Julian Andres Klode julian.klode@canonical.com 2020-04-06T08:00:23Z urn:sha1:d3133f92205e06f1f04e39c7e74db9efb98df19f Recent GnuTLS 3.6.11 -> 3.6.13 update in Ubuntu broke our test certificate, it's signed with SHA1. Regenerate with SHA2. openssl req -newkey rsa:2048 -x509 -sha256 -days 36500 -nodes -out apt.crt -keyout apt.key -subj "/CN=localhost/O=APT Testcases GmbH/ST=Some-State/C=DE" cat apt.key apt.crt > test/integration/apt.pem 2020-03-21T07:35:26Z David Kalnischkies david@kalnischkies.de 2020-03-21T07:14:15Z urn:sha1:bf46e09f0e4b52b3c71ac20bb11e7511fc16179f While merging apt-pkg and apt-inst libraries the codepath of handling deb files in apt-pkg was adapted to use the 'old' code from apt-inst instead of fork&exec of dpkg-deb -I. The information we get this way forms the main part of the package stanza, but we add a few semi-optional fields to the stanza to make it look and work more like a stanza we got from a repository. Just be careful with the area where these two parts touch as if, hypothetically, we would stip all newlines around the parts, but forget to add a newline between them later, the two lines around the merge would stick a bit too close together forming one which could result in fun parsing errors if this merged line was previously e.g. a well-formed Depends line and has now extra fluff attached. This codepath has a history with too many newlines (#802553) though, so how likely is it really that it will some day lack one you may ask. References: 6089a4b17c61ef30b2efc00e270b0907f51f352a