apt/apt-pkg, branch 3.1.7

Add history undo, redo, and rollback features

2025-10-02T10:49:58Z

History Command and Parsing

2025-09-26T16:18:42Z

edsp: Do not skip lines (fixes Architecture reading)

2025-08-26T11:52:57Z

We skipped the Architecture: line because when the outer loop got to it, the inner loop started and read the next line after it. Get rid of the nested loop instead, and first run a loop to find the request line, and then a second loop to parse the request flags. An alternative would be to use a combined loop that supports non-compliant protocol implementations, but that's harder to read and we don't expect there to be any especially on the request side.

edsp: Clear architecture cache

2025-08-26T11:52:57Z

We need to actually use the architecture values we set

Fix indentation compiler warning with clang

2025-08-26T11:51:04Z

This commit fixes the following compiler warning. cacheiterators.h:423:54: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation]

debListParser: Cache `essential` and `myArch` more

2025-08-26T11:49:18Z

Lookup these variables in the constructor once, rather than once per package. This requires a bit of care as debListParser::UsePackage() defaults to "all" for essential when unset, hence we simply change its == "all" comparisons to == "all" || .empty().# This removes any per-paragraph configuration lookups from the file parser. Also parse myArch from ParseProvides down to ParseDepends() as that call ended up causing it to query APT::Architecture *again* since the function we call is static. Together, the removed config lookups safe about 2.3% of cache generation runtime.

solver3: Allow any downloadable version to mark a package as not obsolete

2025-08-26T11:41:35Z

Lots of people have pinned an older version that is no longer installable, or more common yesterday, we saw a lot of people who seemingly manually installed a newer version of a deb than in the repositories, causing the package to be considered obsolete, which does not make much sense. Oops: 4c39d922-410f-11f0-bbf9-fa163ec44ecd Oops: a64054f6-4140-11f0-bbfd-fa163ec44ecd Oops: a32196c1-661d-11f0-a97c-fa163ec8ca8c

solver3: Sort dependency targets against current alternative

2025-08-26T11:41:35Z

Instead of inadvertently sorting dependency targets against the first alternative in an or group, sort them against the current alternative as we should. Otherwise we ended up sorting gnome-shell | notification-daemon With Package: notification-daemon Package: awesome Provides: notification-daemon into gnome-shell | awesome | notification-daemon <-we sorted this part wrongly-> This fixes a minor difference in test-release-candidate-switching in one case, but not the other where the difference was actually caused by the loss of install argument ordering information in the new solver, so just flip the arguments so both solvers produce the same outcome.

Fix stuck acquire queues on partial server errors

2025-06-24T16:47:18Z

When a server responds with two InRelease files, but one is good, and the other indicates a temporary error, we queued the other indices from the good repository for downloading and then queued the retry. The resulting queue ended up with items having fetchAfter=0 before the item with fetchAfter=, causing the Run() loop to not detect a stuck queue. Change the order of the queue such that the highest retry-after items comes first; this ensures that we always see stuck queues. This of course changes the behavior of retries in that if one file fails temporarily we block the entire server. This does seem more beneficial in the common case - if one file fails, probably all of them fail, and there's no point bombarding the server with requests for indices from good repositories until all have failed. The actual root cause is more that the remaining items are Enqueued like this: 1. Enqueue jammy/InRelease (delayed) 2. Enqueue jammy-updates/main all Packages The resulting queue ended up being: jammy-updates/main all Packages jammy/InRelease (delayed) But Enqueue() only calls Cycle() when there are no items in the queue already - after all, any item that is already running will call Cycle() eventually. Or so was the case until we added the retry-after handling. It's unclear why we don't Cycle() all the time when enqueuing a new item, given that our pipeline might not be filled yet, and we could send the request to the server while waiting for data on a running item. Trying to always Cycle() however led to regressions that still need investigating. Given that, this solution certainly is the more easy to reason about one. LP: #2003851

Include standard headers to fix clang compiler error

2025-06-18T14:03:24Z

This commit fixes the following compiler errors. apt-pkg/acquire.cc:833:51: error: no template named 'function' in namespace 'std' apt-pkg/contrib/error.cc:198:59: error: no member named 'front_inserter' in namespace 'std' apt-pkg/solver3.h:44:22: error: no template named 'is_trivially_constructible_v' in namespace 'std' methods/http.cc:1029:24: error: no member named 'inserter' in namespace 'std'