Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.6 2021-06-04T14:45:06Z 2021-06-04T14:45:06Z David Kalnischkies david@kalnischkies.de 2021-06-04T14:15:45Z urn:sha1:a2406cda4dd0aca523183ed6a8b651f06e0e63f9 The code exists since ever, but no other client supports this and the specification like debian-policy isn't asking for this either. What it does do is breaking than all others continue working through: If the filename includes in fact URI encoded bits (hopefully no quotes) which is rather unlikely, but none the less possible. 2021-06-04T14:43:41Z David Kalnischkies david@kalnischkies.de 2021-06-04T11:06:34Z urn:sha1:149b23c2b9697bc262c0af1934c7a3f6114d903f Keeping URIs encoded in the acquire system depends on having them encoded in the first place. While many other places got the encoding 2 out of 3 ArchiveURI implementations were missed which are in practice responsible for nearly all of the URI building, just that index filename do not contain characters to escape and the Filename fields in Packages files usually aren't. Usually. Except if you happen to have e.g. an epoch featuring package with the colon encoded in the filename. On the upside, in most repositories the epoch isn't part of the filename. Reported-By: Johannes 'josch' Schauer on IRC References: e6c55283d235aa9404395d30f2db891f36995c49 2021-05-17T08:25:28Z Julian Andres Klode julian.klode@canonical.com 2021-05-17T08:25:28Z urn:sha1:81eb944c76d99f34b57d7c3efd283c3ffb6e4c1f If a package is not installed yet, we do need to apply phasing as we otherwise get into weird situations when installing packages: In the launchpad bug below, ubuntu-release-upgrader-core was installed, and hence the phasing for the upgrade to it was applied. However, ubuntu-release-upgrader-gtk was about to be installed - and hence the phasing did not apply, causing a version mismatch, because ubuntu-release-upgrader-gtk from -updates was used, but -core from release pocket. Sigh. An alternative approach to dealing with this issue could be to apply phasing to all packages within the same source package, which would work in most cases. However, there might be unforeseen side effects and it is of course possible to have = depends between source packages, such as -signed packages on the unsigned ones for bootloaders. This problem does not occur in the update-manager implementation of phased updates as update-manager only deals with upgrading packages, but does not install new packages and thus does not see that issue. APT however, has to apply phasing more broadly, as you can and often do install additional packages during upgrade, or upgrade packages during install commands, as both accept package list arguments and have the same code in the backend. LP: #1925745 2021-05-05T10:14:11Z Julian Andres Klode julian.klode@canonical.com 2021-05-05T10:14:11Z urn:sha1:6fe716703b2dd5c47cb6684e0b83fd1c52516d41 See https://github.com/Debian/apt/pull/129 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-29T08:26:11Z Julian Andres Klode jak@debian.org 2021-04-29T08:26:11Z urn:sha1:5d81ec308275b625a20b889fa3daa43815ddc80d Mark only provides from protected versioned kernel packages See merge request apt-team/apt!168 2021-04-26T11:00:24Z David Kalnischkies david@kalnischkies.de 2021-03-18T18:08:48Z urn:sha1:6f01e7cc0c6f231711b3b81a81beb3775f0a855a They are kinda costly, so it makes more sense to keep them around in private storage rather than generate them all the time in the MarkPackage method. We do keep them lazy through as we have that implemented already. 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-26T11:00:24Z David Kalnischkies david@kalnischkies.de 2021-03-18T13:40:31Z urn:sha1:9a54e70c1040379fb06827bacb461c61e341e694 The autoremove algorithm would mark a package previously after exploring it once, but it could have been that it ignored some providers due to them not satisfying the (versioned) dependency. A later dependency which they might satisfy would encounter the package as already marked and hence doesn't explore the providers anymore leaving us with internal errors (as in the contrived new testcase). This is resolved by introducing a new flag denoting if we explored every provider already and only skip exploring if that is true, which sounds bad but is really not such a common occurrence that it seems noticeable in practice. It also helps us marking virtual packages as explored now which would previously be tried each time they are encountered mostly hiding this problem for the (far more common) fully virtual package. 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