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 DDD3313877A for ; Sat, 26 Jul 2014 17:50:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C17CEE0F70; Sat, 26 Jul 2014 17:50:37 +0000 (UTC) Received: from os-mail-2.tamu.edu (os-mail-2.tamu.edu [165.91.23.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E2E24E0F53 for ; Sat, 26 Jul 2014 17:50:36 +0000 (UTC) X-TAMU-Auth-ID: t551 X-TAMU-SenderIP: 24.19.135.80 Received: from basis.localnet (c-24-19-135-80.hsd1.wa.comcast.net [24.19.135.80]) (authenticated bits=0) by os-mail-2.itio.tamu.edu (8.14.7/8.14.7) with ESMTP id s6QHoTRK026769 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 26 Jul 2014 12:50:35 -0500 From: Taahir Ahmed To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] don't rely on dynamic deps Date: Sat, 26 Jul 2014 12:47:41 -0500 Message-ID: <4690585.OHUJhsLiQm@basis> Organization: TAMU-CS-DAIRL User-Agent: KMail/4.13.3 (Linux/3.12.21-gentoo-r1; KDE/4.13.3; x86_64; ; ) In-Reply-To: <53D2958D.2000203@gentoo.org> References: <53CD6BED.10603@gentoo.org> <2313928.8HG0gu9JG6@kailua> <53D2958D.2000203@gentoo.org> 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; boundary="nextPart14369159.Adv8uOgTWP"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-07-26_02:2014-07-25,2014-07-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407260242 X-Archives-Salt: 51b97efb-3444-47a3-a36b-2c940cf2323c X-Archives-Hash: 0f4ffbf9fe6a6a3a82d7825d6ba24035 --nextPart14369159.Adv8uOgTWP Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" It seems like a simple before/after comparison of active useflags and the text of the src_* functions (skipping build and install if they are completely identical) should catch the majority of unnecessary rebuilds. On 25 July 2014 13:36 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. > --nextPart14369159.Adv8uOgTWP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT0+nEAAoJEP0dGB2mOaLGwLQIAImGjnR0EBGrwjVA8Ow0WtZp 38Bneg9k7dZwLi7O2Q0LYEU/bTWIeUWQhZOZQYUeGXfHuMVTbyWBvZBq+d64UeDc kT4H+2hYYepBzB+CpB8IHKdYB1RMduxVxa9U80yhqHL+npup8PeJbg3+LBqNYjwO j07zYfARB0/60KWU0YaMV6137J6Y/n2I6cnAxsxTJEzHXcGOhc5jQBbtTvcEbbyT kPQq4IzlQ0WO7NwjTNdaGBlEReBWWjOXeM5dZmIbWukbQ7Vhsz7VtZvWqnlUDqCu aJkJVsv5079JrJDuRixKW80e3yUyIAk+5OVlt3BbaADLHmNJUO1GembZW3Cp2Jg= =fzko -----END PGP SIGNATURE----- --nextPart14369159.Adv8uOgTWP--