On Mon, 12 Jan 2004 15:02:27 +0100 Pieter Van den Abeele <[EMAIL PROTECTED]> wrote:
> > On Sun, 2004-01-11 at 05:01, Spider wrote: > >> Another idea is to have portage install all RDEPEND but not DEPEND > >> -after- the package, thereby locking down even more dependency bugs > >> with malcreated packages. > >> > > This solution leaves the system in an inconsistent state when the > building fails. Installed packages are likely to not work because of > missing runtime dependencies which are not compile time dependencies. > I think that it is already in the air that portage-ng should separate fetching of a package from the rest of its installation task, right? Maybe another interresting split of the "package installation task" would be to separate building from merging. Lets say that we want to merge A, and that we also have to install B and C because of the following unsatisfied dependencies: A --RDEPEND--> B --DEPEND--> C Similarly to the fetch/build split which adds the schedule constraint that you can't build if you've not fetched yet, the build/merge split would add the schedule constraint that you can't merge if you've not built yet, thus, for our example: "build A before merge A" "build B before merge B" "build C before merge C" The "A --RDEPEND--> B" dependency would add: "merge B before merge A" And the "B --DEPEND--> C" dependency would add: "merge C before build B" This constraints set, with a "merge as late as possible" heuristic, would give one of this two schedules: - build A | - build C - build C | - build A - merge C | - merge C - build B | - build B - merge B | - merge B - merge A | - merge A They never break system consistency, but keep the benefits of Spider's suggestion. We can even imagine that this is configurable, and that other users can choose a "merge as soon as possible" heuristic, which would produce a schedule similar to what is done in current portage (build & merge C, then build & merge B, then build & merge A). -- TGL. -- [EMAIL PROTECTED] mailing list
