Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.4 2021-02-12T16:13:57Z 2021-02-12T16:13:57Z Julian Andres Klode julian.klode@canonical.com 2021-02-12T16:13:57Z urn:sha1:5bfc150688ea748595b6535eb1dc5d777baf16e4 std::regex pulls in about 50 weak symbols which is complete and utter madness, especially because we version all our symbols, so no other library could ever reuse them. Avoid using the regular expression here all together, loop using string::find_first_of() and insert backslashes with strng::insert(). 2021-01-11T10:37:11Z Julian Andres Klode julian.klode@canonical.com 2021-01-11T10:37:11Z urn:sha1:edb63b14225c783c673dcac0cc3c60aae076e45c In case we did not find any kernels to protect, the regular expression will be empty, and trying to substr(1) it will fail. 2021-01-08T17:03:08Z Julian Andres Klode julian.klode@canonical.com 2021-01-08T17:03:08Z urn:sha1:24984ac47b0172400e575ad44ed60bb22543298b Gbp-Dch: ignore 2021-01-04T09:54:42Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T14:21:17Z urn:sha1:38c49b8adeadf54f147140b3a5db7693e9b9b50f This fixes a problem on Ubuntu systems where the /boot partition has been sized to manage 3 kernels, but does not really work with 4 kernels which was causing problems all over the place. 2021-01-04T09:46:48Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T12:24:56Z urn:sha1:04085f46dea9a95dd86123ac00187a63cc4ba2c0 Our kernel autoremoval helper script protects the currently booted kernel, but it only runs whenever we install or remove a kernel, causing it to protect the kernel that was booted at that point in time, which is not necessarily the same kernel as the one that is running right now. Reimplement the logic in C++ such that we can calculate it at run-time: Provide a function to produce a regular expression that matches all kernels that need protecting, and by changing the default root set function in the DepCache to make use of that expression. Note that the code groups the kernels by versions as before, and then marks all kernel packages with the same version. This optimized version inserts a virtual package $kernel into the cache when building it to avoid having to iterate over all packages in the cache to find the installed ones, significantly improving performance at a minor cost when building the cache. LP: #1615381 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T16:49:11Z urn:sha1:1f910d94add8f20ebfa5999a7795e678a4af0826 We were traditionally adding points for some dependency types to the real package, but we should also do it for providers of that package to help the resolver especially if the real package is for some reason not tagged for removal yet/anymore. While at it we ensure that the points are only attributed once for each package as especially with versioned provides a package can nowadays provide another many times and would hence acquire a lot of points. 2020-06-03T10:55:02Z David Kalnischkies david@kalnischkies.de 2020-06-03T10:55:02Z urn:sha1:771ddb195586c638cbfc635fa6726733532bcfd0 Especially if a lot packages have to be removed due to not to explicitly expressed conflicts the problem resolver can take a few turns to remove them all. Allowing it to try a little longer if needed seems beneficial as the worst which can happen is that we now take two times as long to present an error message to the user. 2020-06-02T11:14:30Z David Kalnischkies david@kalnischkies.de 2020-06-02T10:47:12Z urn:sha1:8218c642342e431d7e69831bd1a6741b40345bf1 For protected packages the "Fixing" done via KillList in the ProblemResolver will usually not happen as the state change is not allowed, so the debug message is just confusing and the resolver is needlessly looping here (which might push it over the edge), so if we didn't do our thing successfully here we short-circuit a bit to help the next iteration come to a solution. 2020-05-29T10:46:59Z David Kalnischkies david@kalnischkies.de 2020-05-29T10:46:59Z urn:sha1:33e19f1fe1655e2d6883ff8d30226fb7db02dd45 The pkgProblemResolver incorrectly skips protected packages while considering packages for removal, which was always wrong but is now a lot more visible as (potentially) far more packages are considered protected in their state. Note that the testcase shows that we need more changes to make this proper. 2020-05-24T19:02:35Z David Kalnischkies david@kalnischkies.de 2020-05-23T14:22:44Z urn:sha1:2ba86f95bfad4ec00a3b99b311d05c158162b25c For speed reasons pkgDepCache initializes its state once and then has a battery of update calls you have to invoke in the right order to update the various states – all in the name of speed. In debug and/or simulation mode we can sacrifice this speed for a bit of extra checking though to verify that we haven't made some critical mistake like #961266.