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 C19DD13877A for ; Fri, 25 Jul 2014 17:36:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0FEA3E1B69; Fri, 25 Jul 2014 17:36:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2335EE1B5D for ; Fri, 25 Jul 2014 17:36:28 +0000 (UTC) Received: from [192.168.1.195] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id E742B34006F for ; Fri, 25 Jul 2014 17:36:21 +0000 (UTC) Message-ID: <53D2958D.2000203@gentoo.org> Date: Fri, 25 Jul 2014 13:36:13 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] don't rely on dynamic deps References: <53CD6BED.10603@gentoo.org> <1405976767.1013.9.camel@gentoo.org> <20140725000627.34d08221@pomiot.lan> <2313928.8HG0gu9JG6@kailua> In-Reply-To: <2313928.8HG0gu9JG6@kailua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 77b44c9c-d5a6-443c-b8ce-27c0b6bb936a X-Archives-Hash: cff031c039b3a77502269422eaec8ab8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 25/07/14 01:15 PM, Andreas K. Huettel wrote: > >>> Maybe this could be solved by having two kinds of revisions: - >>> One would rebuild all as usually (for example, -r1...) - The >>> other one would only regenerate VDB and wouldn't change the >>> installed files (for example, -r1.1) >>> >>> But I am not sure if it could be viable from a "technical" >>> point of view :( >> >> I'm afraid it couldn't. The major problem is not knowing *when* >> to migrate metadata, portage usually gets that right. The problem >> is in getting the correct output which is often near to >> impossible. > > I think we'd appreciate some more information here: > > * What exactly is the metadata that we're talking about? * How much > of it can be generated by sourcing the ebuild, without running > phases? * When does that exactly break? Example? > It may help this overall discussion to step back even further here: * What do we want to accomplish, exactly? - allow portage to emerge updated packages without rebuilding them (ie running src_* and pkg_*inst phases), when it can be determined from metadata changes (or for -rX.Y method perhaps it is assumed - -just- on filename changes) that this is not necessary. * What are all of the cases that would validly trigger this dont-bother-to-run-phases shortcut? - - addition of missing dependency [1] - - new useflag not enabled by default - - removed useflag that was not previously enabled - - changing of dependency atom(s) -- ie swapping a specific atom to virtual one - - EAPI bump (maybe??) - - .... <-- add more please! * For each of the above, in what cases is a full rebuild probably necessary anyhow?? - - dependency atom minimum version is increased, and the in-VDB version of this dep is too old (??) - - new dependency atom is missing from VDB (??) - - EAPI bump adds new entries to VDB that need to be calculated from say, merge phase - - .... ..i think from there we can perhaps determine what metadata could be updated and/or needs to be updated to maintain consistency in the dont-rebuild cases we want. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPSlY0ACgkQ2ugaI38ACPBDHAD+POgCJlbPv9HHwhK4wxd8b2ir ywM71Aemu6SPfCTE2MIBAKATag94jCHLlqwkYN2jrW23tYqTi5ajOwLzoZ/EqHx0 =qUpY -----END PGP SIGNATURE-----