Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.4 2021-04-29T08:28:08Z 2021-04-29T08:28:08Z Julian Andres Klode jak@debian.org 2021-04-29T08:28:08Z urn:sha1:a6cb741a2cd1fa132705f8f5644872fc9708fb68 Count uninstallable packages in "not upgraded" See merge request apt-team/apt!169 2021-04-26T11:00:24Z David Kalnischkies david@kalnischkies.de 2021-03-18T16:37:49Z urn:sha1:d6f3458badf2cfea3ca7de7632ae31daff5742be An interactive tool like aptitude needs these flags current far more often than we do as a user can see them in apt only in one very well defined place – the autoremove display block – so we don't need to run it up to four times while a normal "apt install" is processed as that is just busywork. The effect on runtime is minimal, as a single run doesn't take too long anyhow, but it cuts down tremendously on debug output at the expense of requiring some manual handholding. This is opt-in so that aptitude doesn't need to change nor do we need to change our own tools like "apt list" where it is working correctly as intended. A special flag and co is needed as we want to prevent the ActionGroup inside pkgDepCache::Init to be inhibited already so we need to insert ourselves while the DepCache is still in the process of being built. This is also the reason why the debug output in some tests changed to all unmarked, but that is fine as the marking could have been already obsoleted by the actions taken, just inhibited by a proper action group. 2021-04-25T14:25:57Z David Kalnischkies david@kalnischkies.de 2021-03-06T13:12:01Z urn:sha1:f90b892e6acc0ca725811ef0dd9be3fed66c444f If a first step of the solver can figure out that a package is uninstallable it might reset the candidate so that later steps are prevented from exploring this dead end. While that helps the resolver it can confuse the display of the found solution as this will include an incorrect count of packages not upgraded in this solution. It was possible before, but happens a fair bit more with the April/May resolver changes last year so finally doing proper counting is a good idea. Sadly this is a bit harder than just getting the number first and than subtracting the packages we upgraded from it as the user can influence candidates via the command line and a package which could be upgraded, but is removed instead shouldn't count as not upgraded as we clearly did something with it. So we keep a list of packages instead of a number which also help in the upgrade cmds as those want to show the list. Closes: #981535 2020-12-18T18:02:05Z David Kalnischkies david@kalnischkies.de 2020-07-08T15:51:40Z urn:sha1:97be873d782c5e9aaa8b4f4f4e6e18805d0fa51c Our http method encodes the URI again which results in the double encoding we have unwrap in the webserver (we did already, but we skip the filename handling now which does the first decode). 2020-10-26T13:39:44Z Julian Andres Klode julian.klode@canonical.com 2020-10-26T13:39:44Z urn:sha1:681f74a8bd5beaad5b821a5c4eb3c0bc1c471669 We accidentally excluded virtual packages by excluding every group that had a package, but where the package had no versions. Rewrite the code so the lookup consistently uses VersionList() instead of FirstVersion and FindPkg("any") - those are all the same, and this is easier to read. 2020-10-26T13:33:55Z Julian Andres Klode julian.klode@canonical.com 2020-10-26T12:54:26Z urn:sha1:9cc002939afc0d2283fd2f5e7d6e7434af5d10ff We passed "false" instead of false, and that apparently got cast to bool, because it's a non-null pointer. LP: #1876495 2020-08-04T10:12:30Z Julian Andres Klode jak@debian.org 2020-08-04T10:12:30Z urn:sha1:11530bab64efd4b4fc46de7833533cea9c69f521 Remove master/slave terminology See merge request apt-team/apt!124 2020-08-04T10:07:10Z Julian Andres Klode jak@debian.org 2020-08-04T10:07:10Z urn:sha1:1afe7c8b874abb61cde591e0241b967ef1b99991 Fully deprecate apt-key, schedule removal for Q2/2022 See merge request apt-team/apt!119 2020-07-14T14:04:56Z Julian Andres Klode julian.klode@canonical.com 2020-07-14T14:04:56Z urn:sha1:9f78677281b8866a28af469dc7f437771f2a1b8f Sorry! 2020-06-23T14:12:41Z Julian Andres Klode julian.klode@canonical.com 2020-06-23T14:12:41Z urn:sha1:b5faca7a90e1aa25adb8ee69b979d1f4bd7e8d78