Week 14: This is CROSS!

Picture me as a messenger kicked into an endless pit of complexity by what was supposed to be an easy victim. It wasn't /that/ bad, but massaging apt to treat crossgrades right took some time – and then some more to request that dpkg would handle some of it, too, as it gets confused by multi-instance packages. Much like apt although that was just effecting apts progress reporting so not that bad… perhaps I am play-testing too much…

In unrelated news I dealt with the two acquire bugs which started last week as such bugs are annoying & carry the risk of being security problems which would require immediate attention. Thankfully non of them seems to be one, but #831762 had me seriously worried for a while. Trivial in retrospective, but getting to a point in which you consider the possibility of that happening at all…

But back to the topic: There was one thing still needed to get our current internal planner a bit "smarter" by enabling options which existed for a while now, but were never activated by default, and that thing was simulation. While its kinda appealing to have the simulation only display what the planner explicitly told use to do, ignoring what would implicitly be done by the --pending calls we can't really do that as this would be an interface break. There are surely scripts out there doing funny things with this output so having it be incomplete is not an option, which in turn means that what I did internally for the progress reporting (and hook scripts) must also be done in the simulation. Easier said then done through as the implementation of it followed a direct approach running the simulation of each action as soon as the action was called rather than collecting all the actions first to post-process them (as I want to do it) and execute them only then. Add to this that this is a public class, so ABI is a concern… the solution I arrived at is slightly wrong, but is going to satisfy all existing callers (which is only aptitude in the archive thanks to codesearch.d.n) and reuses the "dpkg specific" code, which is a layer violation, but reuse is better than copy&paste without breaking ABI, so I am happy all things considered.

So, with that out of the way glory awaits: Changing the default of PackageManager::Configure from "all" to "smart"… and tada: It works! The simulation shows everything, the dpkg invocations are much shorter, trigger executions delayed, we rely more on --pending calls and progress reporting is properly moving forward as well! Not 100% production ready but good enough for a public wip branch for now (= wip aka: going to be rebased at will).

This also includes the barebones 'dpkg' planner I mentioned last week, based on that I was playing with ideas to find a more viable implementation (= handling Pre-Depends) but nothing of particular note produced yet. Maybe I can get something working this week – it is at least part of the plan beside polishing my wip branch – after leaving that pit that is… Hello, is anyone up there? Hello? Hello? …