External dependency solvers in APT

Back in April I talked about me being in Paris, I returned in May but kept more or less silent about it.

Nothing has really changed since then, I just want to write down now how somebody can play with other solvers now before it hits possibly a bigger audience (in case someone actually reads changelogs or such silly stuff).

All you need is:

And you are ready to have some fun, try e.g. apt-get install awesome --solver aspcud

You will notice: It's relatively slow, compared to the internal solver. It might not behave like you would expect the internal solver to behave in regards to pinning or alike.

Best example is APT's own external solver 'apt' – yes, you can use the internal solver as an external solver in case you find another program implementing EDSP – which doesn't implement pinning and a few other bits so far. You are right than you think that this one is mostly only useful for debugging. There is another interesting one: 'dump' – imagine what it does…

So, why is this useful you might ask: In case you find a dependency problem you can now dump this problem easily and run different solvers on it. You can also work on developing the next-generation hyper-intelligent solver and be able to use it in day-to-day situations with the tools you usually use. And as a bug-hunter, you can if you have such a dump reproduce the problem more easily and get your hands dirty while fixing the bug. So this EDSP thing is kind of technical preview. It's not planed to drop the internal solver from APT now or in the near future, don't worry. It's mostly here to enable researchers and developers to play with new deployments in real world situations so that at the end they create something which can be used for implementations which can really be used by "normal" end-users.

(and its here to enable me to throw the sentence: "Heh, if you thing the apt solver is so dumb and you could do it so much better: Why don't you do it for the benefit of all of us?" at everyone complaining without hard facts just because they think nobody listens who will hunt them down and force them to solve all these "utterly trivial problems" on their own. Yes, I am looking at YOU ! 😉︎ )

One week in Paris

(I can't help myself, the title sounds like a good remake of bad stuff - I mean, the remake is bad, but double bad is good, isn't it?)

I am back. After my sheeva and then my kindle returned back to me, I returned home, too. Last week was one of the craziest in my life: You are more or less alone in a big city, hundreds of people passing by and you understand nobody. The only language I can really speak is German, but the masochist in me accepts invitations to America where my rusty English allows me to survive, but how he could accept an invitation to Paris in the knowledge that I don't speak a single word of French?!? I learned two words: 'Bonjour' (hello) and 'Sortie' (exit) in this week. As you can see, I am not a fast learner…

Anyway, it's properly more interesting what I did in Paris: Stefano happens to be working for one of the universities of Paris and in this function for IRILL on mancoosi. In a nutshell: Defining and organizing dependency solving battles by defining a protocol all solvers have to understand and what the response should be.

The week was therefore dedicated to working out a way for APT to talk to external solvers, so that we can use the battle survivors as external solvers for (maybe) better solutions. I will write a bit more detailed how this works (or not) after finishing it in a second stay in May, but so far we have an EDSP which defines an intermediate scenario format which is near to CUDF, but doesn't rewrite versionnumbers and alike as this is internal business a solver doesn't need to do to work with APT. So in practice the cudf solvers will most likely use a common preprocessor on this scenario and be happy. A common postprocessor will then reformat the cudf response to a diff style answer which will be passed to APT which reacts on it and does his "magic".

EDSP is currently an early draft and the implementation in APT more or less half-way finished while EDSP<->CUDF translator is promising, too. All in all we will most likely see something soon in May modulo that it will need an ABI-break in APT which needs a lot of time to be allowed in unstable most of the time.

Time will tell, so far at least from the water-level observation one-man-team here. 😉︎


These are all posts currently tagged EDSP. You can browse a list of all posts tagged EDSP here or subscribe to the RSS feed or Atom feed for this tag to be notified of future posts.