From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6D492138247 for ; Mon, 13 Jan 2014 18:17:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 631BEE0B55; Mon, 13 Jan 2014 18:17:42 +0000 (UTC) Received: from jacques.telenet-ops.be (jacques.telenet-ops.be [195.130.132.50]) by pigeon.gentoo.org (Postfix) with ESMTP id 32F77E0B37 for ; Mon, 13 Jan 2014 18:17:41 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by jacques.telenet-ops.be with bizsmtp id DWHg1n00D2khLEN0JWHgfb; Mon, 13 Jan 2014 19:17:40 +0100 Date: Mon, 13 Jan 2014 19:16:45 +0100 From: Tom Wijsman To: antarus@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) Message-ID: <20140113191645.27872dd8@TOMWIJ-GENTOO> In-Reply-To: References: <1388986435.17870.49.camel@big_daddy.dol-sen.ca> <1389582464.7103.185.camel@big_daddy.dol-sen.ca> <20140113083917.5427344.53422.41690@pathscale.com> <52D3A71F.9040602@plaimi.net> <52D3AEB9.7080500@pathscale.com> <20140113155813.391c403f@TOMWIJ-GENTOO> <20140113163859.61c3df01@gentp.lnet> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/PYbfOoy76xjBNz29dfau5R7"; protocol="application/pgp-signature" X-Archives-Salt: 97a7a188-8550-4f6e-adf6-0b51a6c857dd X-Archives-Hash: 8003f6676d2fa28204d01ca7bb425b35 --Sig_/PYbfOoy76xjBNz29dfau5R7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 Jan 2014 08:49:17 -0800 Alec Warner 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=3D0 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. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/PYbfOoy76xjBNz29dfau5R7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS1C2NAAoJEJWyH81tNOV9aeoH/iJ9y1PTadBLJnl64XXVPqWY nEmiIO6cdLm8heFpS3QmQj3R1R9bH7ePzqmJwtsdsfjTSVMaF5UGXZaOnyumYekR vYjy6h0RsyUe5UoW5jxd2Z5BMjFw/6pWWT2U6ho/A+yFyvWUKtQwmyh7jlfi9agM QBJO5mMA/r7rz/s+oas9Ev2lEGQD8gYGD9SByeoNZrFdu5FXcfjE2py4pnJ1ayZD 9BjNarGz9U7Ss8SFLZiFbzOci1LkSpH2t7m4NDCTyMwds68HizMOUsTYVxPRRSzf I/e/SBXSaS+zhgR1gsoLFK0bdhDxLvDJYVp1bxIh8ftbbfT9pEufTyIx+nKgIGs= =o2U4 -----END PGP SIGNATURE----- --Sig_/PYbfOoy76xjBNz29dfau5R7--