public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
  @ 2014-01-13 16:49 99%               ` Alec Warner
  0 siblings, 0 replies; 1+ results
From: Alec Warner @ 2014-01-13 16:49 UTC (permalink / raw
  To: Gentoo Dev

[-- 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 --]

^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-01-06  5:33     [gentoo-dev] Portage team, Zac's development break and stepping down as lead Brian Dolbec
2014-01-13  3:07     ` Brian Dolbec
2014-01-13  8:39       ` C. Bergström
2014-01-13  8:43         ` Alexander Berntsen
2014-01-13  9:15           ` [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) "C. Bergström"
2014-01-13  9:31             ` Fabio Erculiani
2014-01-13 14:58               ` Tom Wijsman
2014-01-13 15:38                 ` Luis Ressel
2014-01-13 16:49 99%               ` Alec Warner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox