Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.4 2021-04-26T11:00:24Z 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-25T12:23:13Z David Kalnischkies david@kalnischkies.de 2021-03-17T23:47:16Z urn:sha1:acc5502e7bd4bee178b8da3198a376d9001ab414 An out-of-tree kernel module which doesn't see many new versions can pile up a considerable amount of packages if it is depended on via another packages (e.g.: v4l2loopback-utils recommends v4l2loopback-modules) which in turn can prevent the old kernels from being removed if they happen to have a dependency on the images. To prevent this we check if a provider is a versioned kernel package (like an out-of-tree module) and if so check if that module package is part of the protected kernel set – if not it is probably good to go. We only do this if at least one provider is from a protected kernel though so that the dependency remains satisfied (this can happen e.g. if the module is currently not buildable against a protected kernel). 2021-02-12T11:53:57Z Julian Andres Klode julian.klode@canonical.com 2021-02-12T11:53:57Z urn:sha1:3b198616423daaef69c938fbcc5dd11a1e8f866c 2021-02-03T23:48:22Z David Kalnischkies david@kalnischkies.de 2021-02-03T23:48:22Z urn:sha1:f701eb209fcc94e5b4f80656270d2fa21663b364 For years I subconsciously thought this is wrong but ignored it: $ LANG=C apt install -s Reading package lists... Done Building dependency tree Reading state information... Done Then I noticed: $ LANG=C apt install -s -o dir::state::extended_states=/dev/null Reading package lists... Done Building dependency tree... Done That can't be! Then it really should be: $ LANG=C apt install -s Reading package lists... Done Building dependency tree... Done Reading state information... Done This oddity seems to be in since the introduction of the auto bit in 2005 which makes this rather hard to solve in theory, but in practice no front end seems to call the readStateFile method directly, so we might actually be lucky. The alternative would be to call Done in the calling method and again at the end of readStateFile while dropping it from the current place, but as that is more shuffling around it could be more upsetting for other front ends. Not sure, but now that I have seen it, I want to have it fixed one way or another… aptitude at least seems not to explode. References: afb1e2e3bb580077c6c917e6ea98baad8f3c39b3 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 2021-01-04T09:43:31Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T12:20:53Z urn:sha1:290a4cf9455f45895718ed698147061fcd0a2dcb This avoids the cost of setting up the function every time we mark and sweep. 2020-08-04T10:16:36Z Julian Andres Klode jak@debian.org 2020-08-04T10:16:36Z urn:sha1:63c0657ea54c9268bc1855d5eac92bc636532bd6 Support marking all newly installed packages as automatically installed See merge request apt-team/apt!110 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:58:35Z urn:sha1:cfd0172fb0eeb15b2e2427c0e11b2ec65f501839 If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one.