Well, I’m not sure if gentoo/OSX-x86 exists yet…
Someone should buy me a macbook so I can make it happen 🙂
Or better still, 12 inch iBook so that I can *ahem* help with gentoo/osx-ppc
Well, I’m not sure if gentoo/OSX-x86 exists yet…
Someone should buy me a macbook so I can make it happen 🙂
Or better still, 12 inch iBook so that I can *ahem* help with gentoo/osx-ppc
So, initially I thought that the best way for the resolver to find the best path would be for each node in the depgraph, to instantiate a new ‘resolver’ object.
Now, I’m not so sure. I think the entire depgraph ought to be built using associative arrays.
In other words, package A is/contains a touple pointing to C and W (it’s dependencies) flagged as DEPS, and D and R flagged as REVDEPS.
The reason why I was thinking the first idea was because (in my mind) it would’ve been easier to linearize. Brian’s code is not bad at that currently, so I’ve switched focus from trying to find the best install path, to simply building a graph data structure (which, it occurred to me, is a better idea anyway. The graph needs to be built before it can be examined/scored 😉 )
Now, that said, it should make revdeps with slotting easier too. A package that depends on foo can keep it’s dependency without being changed. We don’t need to rebuild the graph in that case if there aren’t version restrictions. It lets the node know that there are 2 versions of a package attached to it.
Okay, so this is all set up. I should leave an update what I’ve been up to the last couple weeks (Google announced I’ve been selected about two weeks or so ago I guess…).
Last couple weeks I’ve been brushing up on python, reading through pkgcore’s source, talking with ferringb and so forth. I’ve also driven in to Vancouver to pick up a couple books on graph theory, I’m about halfway through one of them (Introduction to Graph Theory). If I get nothing else out of this book, I’ll at least have the vocabulary to find tackle the problem I’m looking for