| 1 |
On Fri, 07 Nov 2014 19:11:04 +0100 |
| 2 |
Jauhien Piatlicki <jauhien@g.o> wrote: |
| 3 |
> Then the same question for you: where can one read about the algorithm |
| 4 |
> Paludis uses? |
| 5 |
|
| 6 |
It's basically a two stage process: simple constraint solving using |
| 7 |
value ordering heuristics to enforce "don't do unnecessary work", then |
| 8 |
ordering (which is not quite a graph process, and which is not as |
| 9 |
simple as a topological sort, because the tree is full of circular |
| 10 |
dependencies). |
| 11 |
|
| 12 |
But the interesting question isn't "what's the algorithm?", it's |
| 13 |
"what's the model?". That's where the complexity lies: figuring out how |
| 14 |
to turn *DEPEND specifications into constraints is an utter pain, and |
| 15 |
it isn't clean or easily understandable. The primary reason is || |
| 16 |
dependencies: developers like to write not-really-correct and utterly |
| 17 |
unobvious dependency strings rather than asking for new syntax so they |
| 18 |
can just say what they mean... |
| 19 |
|
| 20 |
> And, again, I have herd (did not try myself) that Paludis is as slow |
| 21 |
> as Portage. |
| 22 |
|
| 23 |
Well, you're not comparing like with like. Paludis with "everything |
| 24 |
turned off" does more than Portage with "everything turned on". If all |
| 25 |
you're looking for is the wrong answer as fast as possible, there are |
| 26 |
easier ways of getting it... |
| 27 |
|
| 28 |
-- |
| 29 |
Ciaran McCreesh |
Archives