On Mon, 13 Jan 2014 08:49:17 -0800 Alec Warner <anta...@gentoo.org> wrote:
> 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. It sounds crazy to use gentoo-x86 without a cache; to some extent, the earlier mentions on this ML by Ciaran that we should improve input would make more sense if would want to run without a cache. But I feel like this shouldn't be a topic of discussion unless we intent 'works fast on a plain CV checkout' to be an actual feature. I haven't checked, but doesn't Portage in that case build its own cache? > 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.) If we document how to process --depgraph=0 output, I believe it could just as well be used; but yes, it basically involves having to run a few manual upgrades (emerge -1 ...) and/or masks to get going. But you can do those things in seconds rather than to wait a few minutes... Some of these Portage could even do automatically regradless, like for instance the 'no parents' slot conflicts; in which case I think you can just always upgrade to the newer version, instead of outputting them it put them as upgrades at the end of the emerge list I think. But I haven't investigated that further, I'm just getting tired of seeing 'em. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
