On Feb 3, 2014 9:17 PM, "Alan McKinnon" <alan.mckin...@gmail.com> wrote: > > On 03/02/2014 16:04, Pandu Poluan wrote: > > > > On Jan 28, 2014 5:57 AM, "Neil Bothwick" <n...@digimed.co.uk > > <mailto:n...@digimed.co.uk>> wrote: > >> > >> On Mon, 27 Jan 2014 22:54:28 +0100, hasufell wrote: > >> > >> > >> If it's about performance (in the sense of speed), then paludis > >> > >> is worse, because dependency calculation is more complex/complete > >> > >> there. > >> > > > >> > > That makes no sense at all. Paludis is written in a different > >> > > language using different algorithms. It's not about the amount of > >> > > work it does so much as how efficiently it does it. > >> > >> > That's exactly what I was saying. I was talking about speed, not > >> > efficiency. > >> > >> But the efficiency of the algorithm, and the language, affects the speed. > >> You can't presume "it does more, therefore it takes longer" if the two > >> programs do things in very different ways. > >> > > > > I was thinking: is it feasible, to "precalculate" the dependency tree? > > Or, at least "preprocess" all the sane (and insane) dependencies to help > > portage? > > > I thought that's what the portage cache does, as far as it can. > > True, the cache reflects the state of the tree and not the parts of the > tree a given machine is using, so how big a diff does that give? And > don't forget overlays - they can slow things down immensely as more > often than not there's no cache for them unless the user knows to do it > manually. >
Well, AFAIK, portage needs to kind of simulate everything going on in an ebuild to get the list of dependencies/blockers... If this can be 'pre-simulated' resulting in a simpler to parse 'database' of dependencies... Rgds, --
