On Feb 3, 2014 9:17 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On 03/02/2014 16:04, Pandu Poluan wrote:
> >
> > On Jan 28, 2014 5:57 AM, "Neil Bothwick" <neil@digimed.co.uk
> > <mailto:neil@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,
--