Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel <aranea@aixah.de> wrote:

> On Mon, 13 Jan 2014 15:58:13 +0100
> Tom Wijsman <TomWij@gentoo.org> wrote:
>
> > On Mon, 13 Jan 2014 10:31:56 +0100
> > Fabio Erculiani <lxnay@gentoo.org> wrote:
> >
> > > Portage can still take *minutes* to calculate the merge queue of a
> > > pkg with all its deps satisfied.
> >
> > Half a minute if you disable backtracking which you don't need. :)
>
> Which sadly also means that some updates get skipped silently. (Those
> which would trigger rebuilds of other packages because of sub-slot
> deps, had that case yesterday).
>
> > > Ironically, launching the same emerge command twice, will take more
> > > or less the same time.
> >
> > Determinism results in more or less the same time, that's correct;
> > proper benchmarks would show you a similar result.
>
> I guess he means that the (according to the file sizes) extensive
> caching doesn't seem to be of much use.
>

The caching may not be of use, depending on your configuration. (For
example, if you use a gentoo-x86 checkout as your main repo, you will
probably want to run generate cache entries whenever you cvs up.) It is
there to cache ebuild metadata, because if your depgraph has a few thousand
nodes, having to spawn bash to generate the metadata for every node is very
expensive. That being said, for most users that use rsync, the metadata is
pre-generated. As long as they are not changing the cache indicators (not
sure if this is mtime or md5sum these days) they should be seeing a benefit.

This is not meant to imply that portage is always fast; there are plenty of
other modules (such as the aforementioned backtracking) that can take a
long time to find solutions. That is partially why you see Tomwij turning
off that feature. It is helpful for users cause it can automatically find
solutions for users that are otherwise unsolvable (and thus avoids the user
having to find a solution to the depgraph manually.)

-A


>
> --
> Luis Ressel <aranea@aixah.de>
> GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD
>

[-- Attachment #2: Type: text/html, Size: 2954 bytes --]