Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.7 2024-07-16T11:55:07Z 2024-07-16T11:55:07Z Julian Andres Klode julian.klode@canonical.com 2024-07-16T11:54:11Z urn:sha1:62573e3ca6b45b0d12b9be8b02da116ce0d91b75 More code but nicer to read 2024-07-02T18:10:33Z Julian Andres Klode julian.klode@canonical.com 2024-07-02T16:56:40Z urn:sha1:a16350427b8ce3865d2f11e637952210d34ee410 Run clang-format 2024-07-02T18:10:33Z Julian Andres Klode julian.klode@canonical.com 2024-07-02T16:53:33Z urn:sha1:ae141932d8b434098e3f77c75c428ca8caff9a6e If we are not upgraded, we should continue to keep the installed package installed if possible. 2024-07-02T18:08:38Z Julian Andres Klode julian.klode@canonical.com 2024-07-02T16:51:11Z urn:sha1:8c13d9cb1c38ebb52cf6e1c8c7561c5c5d87c970 This makes more sense, as all package versions are obsolete that are not the candidate, usually. Pay special attention to no-strict-pinning: If we don't have strict pinning, a package without a candidate version may still be non-obsolete if the latest version is not obsolete. Likewise, in no-strict-pinning any later source version that exists will cause the package to be considered obsolete, rather than just candidates. 2024-07-01T19:49:26Z Julian Andres Klode julian.klode@canonical.com 2024-06-13T15:55:10Z urn:sha1:b69f11fac9f4df52726ea7ac4f2c5920b7f71ccb Refactor the various Install requests into a single one and move some stuff around, this should be a bit easier to maintain and we don't repeat ourselves all the time. This accidentally uncovered some bugs in the code, that get fixed by this: - The UpgradeManual and InstallManual groups did not work correctly, Essential packages were Install and others were Upgrade. - Automatically installed packages falsely got promoted to the manual groups as they got promoted into the manual code path, whenever we ran without allowing their removal. - The combination of --mark-auto --auto-remove now works correctly We previously skipped the installation of automatically installed packages when we did autoremoval, but we did not consider if the action was protected, that is specified on the command-line. Now we do not autoremove protected actions, and have added a test case for it. - The AllowRemoveManual option no longer is applied if removals are generally denied. Closes: #1071519 2024-07-01T15:15:54Z Julian Andres Klode julian.klode@canonical.com 2024-06-13T15:54:13Z urn:sha1:7217910e75ce32938d28f9d653dec6b1d18e05b7 We should set the Mark/Garbage flags for all packages so we don't end up in an inconsistent state, so reset the flags for each package before evaluating further. 2024-07-01T14:28:53Z Julian Andres Klode julian.klode@canonical.com 2024-07-01T14:27:15Z urn:sha1:b636668788fe8b1f7183b21eaf7b87f34209169e As part of the refactoring, we allowed the code to work on unimportant dependencies as we needed to promote Suggests to Depends if they are currently satisfied. However, Replaces and Enhances were not considered properly and both are not negative dependencies so they were accidentally promoted to Depends too if they were currently satisfied. 2024-06-13T13:10:06Z Julian Andres Klode julian.klode@canonical.com 2024-06-06T09:19:04Z urn:sha1:6708203296911800caf94bb94ce204d3a39af0bd This has two aspects: 1. For a dependency A | B | C we order the obsolete packages last, that is, if A is obsolete, this gets reordered to B | C | A, such that we try to pick non-obsolete packages first to ease upgrade calculation. 2. When comparing two dependencies, we order dependencies into three groups: First we satisfy dependencies mentioning only non-installed (NEW) packages, then we satisfy "normal" dependencies, and finally we satisfy any dependencies mentioning obsolete packages. This means for example if you have obsolete libfoo1 and a new libfoo1t64, that we will see Depends: libfoo1t64 before any Depends: libfoo1 (which may expand to libfoo1 | libfoo1t64), so we effectively will have selected "replacement" packages this way already before getting to older packages where we would have to choose between the obsolete package and its replacement. 2024-06-13T13:10:06Z Julian Andres Klode julian.klode@canonical.com 2024-06-06T09:17:09Z urn:sha1:3b5379e547dfb655d764f7eb1ac7eaa5b2d34d6d Comparing the size of work items is not strictly needed; we check if items have a single or no solution and propagate them early on, but it doesn't matter much if we solve A|B or C|D|E first. This will allow us to get rid of all the resizing business later on, and switch to using literal watching where we only watch one of the literals on the right hand side. Likewise, the upgrade case mattered initially in testing, but seems to have resolved itself. 2024-06-13T13:10:06Z Julian Andres Klode julian.klode@canonical.com 2024-05-25T07:45:39Z urn:sha1:102017ecaa01a733a0860a62edae60cb0ab0220e Our backtracking is chronological, so we will first try alternative choices or skip optional items in later groups. So installing manually installed packages before automatically installed ones allows manually installed packages to remove automatically installed packages easily. If we did automatic packages first, we'd keep back upgrades for manual packages or change choices for their dependencies, or would have to backtrack harder to get back to the right decision level. That's silly. Ordering automatically installed packages last also allows us to calculate autoremovable packages. Since we will have installed all dependencies from manually installed packages by the point where we get to automatically installed packages, everything that will be installed in those Auto groups is inherently garbage.