Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.11 2024-07-15T17:17:55Z 2024-07-15T17:17:55Z Julian Andres Klode julian.klode@canonical.com 2024-07-15T17:13:58Z urn:sha1:47deb766c0a11c54d122197531279677545459af Algorithms not in the next level give a warning, algorithms in not in the future level introduce an audit message for the --audit flag. next: >=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512 future: >=rsa3072,ed25519,ed448 LP: #2073126 2024-05-24T11:43:56Z Julian Andres Klode julian.klode@canonical.com 2024-05-24T11:42:11Z urn:sha1:67a8a6470ddb8a603db02c5fab84aa225dc00f8d This is mostly going to be useful for the test suite for now, implement a function there to set it up so we can use it to improve test suite correctness. 2024-05-14T09:56:18Z Julian Andres Klode julian.klode@canonical.com 2024-05-06T13:34:33Z urn:sha1:89dcc342e17dd2439d97a5d27200cf5c26ba35bc This is a simple backtracking brute-force solver with heurisitcs, this initial version has the following known gaps: - Errors are not kept from branches, the error reporting after backtracking isn't particularly useful. - We cannot show automatically removed packages - We cannot replace packages with others - We do not have conflict-driven clause learning yet Untested: - Multi-arch This solver is fundamentally different in key aspects: - It solves smaller dependency groups before larger ones, leading us to avoid installing A in A|B if B is installed more often and more consistently. - It only keeps the automatic packages reachable via the strongest path. Currently it only implements autoremoval, but not display of autoremoval as we simply enqueue all automatically installed packages at the end when not doing automatic removal. This will need some translation where we Solve() first, and then Solve() again with the automatically installed packages added such that we can mark them as Garbage for display purposes. - It does not remove manually installed packages. Hook the solver in via the EDSP framework, this allows us to achieve easy initial integration without lots of issues. A lot of this work was planned and executed in my free time and then some leaked into work time I suppose. Implementation notes: - Restore the full backlog of items The annoying thing is that we record only when an item was enqueued and not the level at which it was installed, so when going back a decision level we might have to reinstall packages that were queued at an earlier decision level because they were only installed at a later decision level. - When picking one version, reject the others - Propagate conflicts up to reverse dependencies This will recursively mark every reverse dependency that can no longer be satisfied as MUSTNOT. Also make sure to recursively call Reject(Ver) from Reject(Pkg) to make sure we trigger the Rejections there. This means we now end up having Recursion in the algorithm. An alternative approach would be to push *reject* items to the heap and then do them, but this is not entirely straight forward and it may simply not be necessary. - Sort upgrades before other optional installs containing subsets If I want to upgrade a package A, I schedule A3|A2|A1; if another thing depends specifically on A1; we'd not be installed. Hence we need to sort upgrades first. This only is needed for optional packages; manual packages will figure this out naturally. - Rescoring is lazily implemented. Instead of calling make_heap() after rescoring items, we just mark the items as dirty and reinsert them. We also only rescore from the main solve loop, Reject() marks the heap as needing a rescore due to a Conflict (as some versions will no longer be installable), and RescoreWorkIfNeeded() then will do the rescoring. - Recursive unit propagation: Install() and Reject() recursively call each other to promote decisions across single-version dependencies (or across not-anymore satisfiable reverse-depends). - Make Reason constructors explicit, this enhances readability This makes calls like the one in here be Reject(object, Reason(otherObject)) Ensuring that it's clear that the 2nd argument is a reason at the caller side. - Split Decision into Decision and Hint vs. first draft When branching/deciding, we do not want to override SHOULD and MAY. We do not actually use them yet, and we do actually clean them when backtracking, but let's at least keep the data structure correct. Convert the enum to a 16-bit integer so we can still fit in the same space as before. 2024-04-22T17:31:46Z Julian Andres Klode jak@debian.org 2024-04-22T17:31:46Z urn:sha1:20ab001670226e92ca8a74f1e2308197111a8420 UI changes for 2.9.2 See merge request apt-team/apt!343 2024-04-19T18:54:54Z Julian Andres Klode julian.klode@canonical.com 2024-01-23T17:43:13Z urn:sha1:215b184d6a5774df10cabe12bde7d6b0fa3aff85 This option is recommended to be used by repository operators for testing. 2024-04-19T18:49:05Z Julian Andres Klode julian.klode@canonical.com 2024-04-15T15:51:26Z urn:sha1:ae1ff72fbee8b3f5d063e8baa86a64e3da11aeb2 We should pass this properly to the TagSection.write() 2024-04-19T18:49:05Z Julian Andres Klode julian.klode@canonical.com 2024-04-15T15:45:47Z urn:sha1:3f5e368ba800f823b36931ced783d450ec621264 2024-04-13T18:27:48Z Julian Andres Klode jak@debian.org 2024-04-13T18:27:48Z urn:sha1:f7e5ed3c8dffcdfc2c55c63f2e3cbcb390bbf013 Calculate an estimate of 110% of the biggest initrd + system.map as the additional space a kernel needs in /boot. If /boot is a different file system than /usr, print the size of the kernels + the additional space they will need separately; otherwise include it in our /usr figure. 2024-04-12T13:57:36Z Julian Andres Klode julian.klode@canonical.com 2024-04-11T21:04:43Z urn:sha1:abfae1aec588c1b4ae46f229d8312a3c5e6b8b7a The key talking points here are: 1. Instead of long sentences, we use short concise messages, e.g. "The following NEW packages will be installed" becomes "Installing". 2. Dependencies are only listed once. We removed the "The following additional packages will be installed" section in favor of splitting up the "Installing" section into "Installing" and "Installing dependencies" (like dnf) 3. The order of the output is different: 1. Packages to be installed manually 2. Packages to be installed automatically 4. Weak dependencies of new packages not installed 3. Packages to be upgraded 4. Packages to be downgraded 5. Packages that have been kept back / are on hold 6. Removals 7. Essential removals i.e. we logically show you the action that is being done, followed by lists related to the action. 4. As requested by popey, we have colorful UI, with green for packages being installed and red for packages being removed. Caveats: - The list of recommends and suggests has not been updated yet, it should move to after the packages being installed (as they are what triggers them) This also introduces output format versioning, configured by the APT::Output-Format option. The default value is 0, except for the apt(8) binary where it is 30 - which enables the new style. 2024-04-12T13:57:05Z Julian Andres Klode julian.klode@canonical.com 2024-04-12T10:00:45Z urn:sha1:8ddfeb2fb65dd45267d8f7abfc540d2b8cb73a5c It's interesting to the user to see the progress when it happens, but arguably once it's done it is just visual clutter, so let's not write newlines, and when we are done, instead of appending "Done", let's just empty the line. This requires some effort to keep apt-cdrom happy which just writes lines to stdout itself. Bad apt-cdrom. Maybe there is a better fix for it, but this gets us going.