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 6278013877A for ; Fri, 25 Jul 2014 17:39:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 47ACBE19FD; Fri, 25 Jul 2014 17:39:45 +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 47113E19EE for ; Fri, 25 Jul 2014 17:39:44 +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 02ACE3400D7 for ; Fri, 25 Jul 2014 17:39:42 +0000 (UTC) Message-ID: <53D29657.7070503@gentoo.org> Date: Fri, 25 Jul 2014 13:39:35 -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> <53D2958D.2000203@gentoo.org> In-Reply-To: <53D2958D.2000203@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8bf1fcf7-16e1-42f0-8910-8bbb78dab1e0 X-Archives-Hash: 7ea83f75613ee5a40de2fd351e6419a6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 25/07/14 01:36 PM, Ian Stakenvicius wrote: > 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. > I forgot: [1] since the package has merged prior to this anyhow, whatever dependency it was must have been installed already when this package was emerged. So if it can still be found in vdb then we should be safe to add the dependency to vdb of this package, otherwise we may need to trigger a rebuild. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPSllcACgkQ2ugaI38ACPCL3QD+ITe3bzJrJIORniniY9rzTEd5 W5nmL5zB+HiZuMZKdZQA/jrn88lx8bfn/f6DetPdrYiFjjShcXoeMbh5nCNmtcz9 =LEAi -----END PGP SIGNATURE-----