Week 3: The thing not called EIPP

IT'S ALIVE! Lacking a better name, I still call this Frankenmonster EIPP as it shares as intended parts of code and overall protocol design with its big sister EDSP with parts tacked on and modified as needed…

The week started with 2 EDSP bugs: 1. rather simple and contained: apt was telling EDSP solvers about packages in 'rc' (removed, but conf files still present) it only knows about from dpkg's status file. Such packages aren't installed & can't be installed (if there isn't an other source available), so giving this version to the solver can allow it to pick this version for installation, which apt can't do. Hilarity ensues. A rather uncommon situation through.

The second was more interesting: apt in combination with an external solver backed by apt-cudf (like aspcud used on buildds for experimental) refused to work if it had to upgrade a package. Just upgrade… #823906.

We discussed that a bit, but eventually decided that its a problem in the EDSP protocol description, APT should verify the protocol assumption & apt-cudf shouldn't generate Install+Remove requests for upgrades.

The work on this bug also highlighted a inconsistency in the documentation of the config options for solvers and their strict-pinning and preferences string, which was corrected as well.

Further, I pushed for a change in the request formulation for {dist-,}ugrade requests to support all three modes of operandi apt has by now, but that generated no response so far. I will give that some more time…

(all of the above is already in git master branch)

But I am here to talk about EIPP: apt can now formulate a request, generate a scenario and as it would be hard to test otherwise apt can also call an external planner now instead of the internal one – and one is already implemented: dump – ripped without changing a bit, just symlinking it into another directory collects the data just fine thanks to the very similar protocol syntax (at least, good enough for now).

An EIPP scenario looks completely different to an EDSP scenario on closer inspection: Very few data points are passed via EIPP – perhaps it should be more, but for the moment I opted for very few data bits.

The very first change to the initial implementation was hence the reduction of the amount of versions apt will generate information for inspired by the first EDSP bug mentioned above: No point in sending information about versions over which are neither installed nor are going to, which can eliminate entire packages from the output as well if nothing of interest forms a dependency on them.

For next week I want to look into how and if I can uplift some of this avoidance code to EDSP to remove packages from the scenario which can't be part of the solution, I would like EIPP to avoid mentioning dependencies which are satisfied the entire time as smaller scenarios means less data to parse and shuffle around for everyone (beside that less data is also easier to 'anonymize' if we ever explore "cloud solutions") and slowly venture into part 2 (of 3) of this project (now that official code start is around the corner): Looking into having our internal planner available as an external one similar to how the external solver 'apt' is our internal solver working over EDSP. That will need fixating the second part of the protocol (= answer) which currently just reads "TODO".

This code lives in a private wip branch ATM only, but I hope with the potential generalizations for EDSP I can move most of it out of them. I would just like to avoid EIPP ending up in master for the time being as nothing is fixed – and with apt we have a kind of "if code was released, you have to support it for years to come" arrangement I would like to avoid as long as I haven't even decided on the name for this monster. 😉

See you next week.

(Next weeks report will likely be written on monday or even a bit later as the weekend will be super busy in reallife for me, so don't wonder).