| 1 |
On Fri, 9 Nov 2007 22:40:08 +0000 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote: |
| 3 |
> Is the following set sufficient? Is the following set the least |
| 4 |
> restrictive correct solution? |
| 5 |
|
| 6 |
... to explain the implications of these... |
| 7 |
|
| 8 |
Say we have packages a, b and c, and none of them have any |
| 9 |
dependencies. One valid solution to the build ordering is as follows: |
| 10 |
|
| 11 |
* Install a |
| 12 |
* Install b |
| 13 |
* Install c |
| 14 |
|
| 15 |
One of many solutions that is *not* valid is: |
| 16 |
|
| 17 |
* Start doing a, b and c in parallel. Install them as they become |
| 18 |
ready, doing only one merge at once. |
| 19 |
|
| 20 |
Another that is not valid is: |
| 21 |
|
| 22 |
* Start doing a, b and c in parallel, but don't merge them. |
| 23 |
* Merge a. |
| 24 |
* Merge b. |
| 25 |
* Merge c. |
| 26 |
|
| 27 |
One that is valid is: |
| 28 |
|
| 29 |
* Build binary packages for a, b and c in parallel. |
| 30 |
* Merge a's binary. |
| 31 |
* Merge b's binary. |
| 32 |
* Merge c's binary. |
| 33 |
|
| 34 |
Another trickier situation. Say a-1 is installed, and a-2 and b are |
| 35 |
targets, and b deps upon a (any version). By the rules given, this is |
| 36 |
allowed: |
| 37 |
|
| 38 |
* Build binary packages for a-2 and b in parallel. |
| 39 |
* Merge a-2's binary (and clean a-1). |
| 40 |
* Merge b's binary. |
| 41 |
|
| 42 |
The situation becomes a whole lot more fun when, for example, we have |
| 43 |
ten packages with interdependencies, and we only want to build at most |
| 44 |
three things at once. That's why it pretty much has to be defined in |
| 45 |
terms of invariancies and exclusivities rather than by listing a small |
| 46 |
set of permitted algorithms. |
| 47 |
|
| 48 |
-- |
| 49 |
Ciaran McCreesh |
Archives