Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.13 2021-11-17T16:21:03Z 2021-11-17T16:21:03Z Julian Andres Klode julian.klode@canonical.com 2021-11-17T16:20:29Z urn:sha1:21cc694f55de7caede8dcef3831236b6ca855cd7 Let's make this one step harder. 2021-07-01T09:34:04Z Julian Andres Klode julian.klode@canonical.com 2021-07-01T09:34:04Z urn:sha1:690f6191a4332123a912c812a19a37cef253e90c We just used the pointer returned which might be nullptr, properly call BuildSourceList() and check the result first. Closes: #990518 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 2021-04-23T10:26:46Z Julian Andres Klode julian.klode@canonical.com 2021-04-23T08:36:18Z urn:sha1:dc11a4422d99cb49817c827b9f827617b5880600 This enables hooks to output additional information. 2021-01-08T12:22:30Z Julian Andres Klode julian.klode@canonical.com 2021-01-08T12:22:30Z urn:sha1:5fddde78ad15e1f6160f65465139d2c1e416d047 Automatically removing kernels in apt-get could be unexpected, so limit it to apt for now. To handle --no-auto-remove correctly, rewrite the hack that makes apt ignore APT::Get::AutomaticRemove options from config files such that it unsets the option. This then means we can do FindB("APT::Get::AutomaticRemove", true) as the default for APT::Get::AutomaticRemove::Kernels and get the behavior we want: If you set --no-auto-remove, it is respected as that FindB returns false; if you don't set it, it will be true. 2021-01-04T09:54:42Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T14:19:53Z urn:sha1:944baec85a7496c1595242a31f6b1b37530451a5 Kernels clutter /boot and /boot is small size, so we need to take extra care to remove kernels when possible. 2019-07-08T13:51:17Z David Kalnischkies david@kalnischkies.de 2019-07-08T13:48:59Z urn:sha1:2b734a7ec429825c7007c1093883229e069d36c7 Reported-By: cppcheck 2019-02-26T15:31:20Z Julian Andres Klode julian.klode@canonical.com 2019-02-26T12:21:07Z urn:sha1:29465ea9555a453ca733280955505de8bfcce935 Please use the standard C++ variants instead.