| 1 |
On Mon, 12 Jan 2004 15:02:27 +0100 |
| 2 |
Pieter Van den Abeele <pvdabeel@g.o> wrote: |
| 3 |
|
| 4 |
> > On Sun, 2004-01-11 at 05:01, Spider wrote: |
| 5 |
> >> Another idea is to have portage install all RDEPEND but not DEPEND |
| 6 |
> >> -after- the package, thereby locking down even more dependency bugs |
| 7 |
> >> with malcreated packages. |
| 8 |
> >> |
| 9 |
> |
| 10 |
> This solution leaves the system in an inconsistent state when the |
| 11 |
> building fails. Installed packages are likely to not work because of |
| 12 |
> missing runtime dependencies which are not compile time dependencies. |
| 13 |
> |
| 14 |
|
| 15 |
I think that it is already in the air that portage-ng should separate |
| 16 |
fetching of a package from the rest of its installation task, right? |
| 17 |
Maybe another interresting split of the "package installation task" |
| 18 |
would be to separate building from merging. |
| 19 |
|
| 20 |
Lets say that we want to merge A, and that we also have to install B and |
| 21 |
C because of the following unsatisfied dependencies: |
| 22 |
|
| 23 |
A --RDEPEND--> B --DEPEND--> C |
| 24 |
|
| 25 |
Similarly to the fetch/build split which adds the schedule constraint |
| 26 |
that you can't build if you've not fetched yet, the build/merge split |
| 27 |
would add the schedule constraint that you can't merge if you've not |
| 28 |
built yet, thus, for our example: |
| 29 |
|
| 30 |
"build A before merge A" |
| 31 |
"build B before merge B" |
| 32 |
"build C before merge C" |
| 33 |
|
| 34 |
The "A --RDEPEND--> B" dependency would add: |
| 35 |
|
| 36 |
"merge B before merge A" |
| 37 |
|
| 38 |
And the "B --DEPEND--> C" dependency would add: |
| 39 |
|
| 40 |
"merge C before build B" |
| 41 |
|
| 42 |
This constraints set, with a "merge as late as possible" heuristic, |
| 43 |
would give one of this two schedules: |
| 44 |
|
| 45 |
- build A | - build C |
| 46 |
- build C | - build A |
| 47 |
- merge C | - merge C |
| 48 |
- build B | - build B |
| 49 |
- merge B | - merge B |
| 50 |
- merge A | - merge A |
| 51 |
|
| 52 |
They never break system consistency, but keep the benefits of Spider's |
| 53 |
suggestion. |
| 54 |
|
| 55 |
We can even imagine that this is configurable, and that other users can |
| 56 |
choose a "merge as soon as possible" heuristic, which would produce a |
| 57 |
schedule similar to what is done in current portage (build & merge C, |
| 58 |
then build & merge B, then build & merge A). |
| 59 |
|
| 60 |
|
| 61 |
-- |
| 62 |
TGL. |
| 63 |
|
| 64 |
-- |
| 65 |
gentoo-dev@g.o mailing list |
Archives