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 AF11813877A for ; Tue, 22 Jul 2014 13:54:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E04EDE0FA9; Tue, 22 Jul 2014 13:54:00 +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 F2FE4E0F83 for ; Tue, 22 Jul 2014 13:53:59 +0000 (UTC) Received: from [192.168.1.130] (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 0834133FD91 for ; Tue, 22 Jul 2014 13:53:58 +0000 (UTC) Message-ID: <53CE6CED.1060300@gentoo.org> Date: Tue, 22 Jul 2014 09:53:49 -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> <201407212153.04605.dilfridge@gentoo.org> <20140721205527.142cb3d5@googlemail.com> <1405976767.1013.9.camel@gentoo.org> In-Reply-To: <1405976767.1013.9.camel@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: cc6f509b-e96c-433e-9e3c-e27dafea1949 X-Archives-Hash: daad7d88b13844235c22b091b021f045 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21/07/14 05:06 PM, Pacho Ramos wrote: > El lun, 21-07-2014 a las 20:55 +0100, Ciaran McCreesh escribió: >> On Mon, 21 Jul 2014 21:53:04 +0200 "Andreas K. Huettel" >> wrote: >>> Revision must be bumped when the on-disk files installed by >>> the ebuild are changed. Nothing about dependencies. >>> >>> This has been policy for a LONG time, and we're not going to >>> change it overnight just because you protest. >> >> Policy used to be that you'd do a revbump when you wanted users >> to reinstall stuff, and you wouldn't otherwise. The only >> complication is that sometimes you want users to reinstall stuff >> so that there's accurate dependency information available, rather >> than because something has changed. >> > > 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 :( > > eww, no. Using ${PVR} to detect how portage should update things would be asking for trouble, imo. Besides, I don't think detection of when to just update VDB is the issue. The main issue that I see is - -how- VDB should be adjusted based on what changes are made to the ebuilds. For instance, if minimum versions of deps are adjusted in-place, should vdb be updated to match? what happens if the minimum version of the currently-installed dep is below the new one? etc. etc. Also, in theory an EAPI bump with nothing else changing should be re-generatable in the VDB, but i have a gut feeling (no evidence, just a feeling) that going from say, EAPI2 to EAPI5 without doing some of the phase functions again (ie 'merge', maybe there are others that can affect VDB?) will result in a different VDB from a regular rebuild. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPObO0ACgkQ2ugaI38ACPCerQEAgTgQOvCDl0dbB5sOOZ4diBNs cheQR18XFo7MsVBX3uUA/0zP1cAiWy1zAF+crrfCC42krtvGmSSiU4JG0dFo4452 =iNmo -----END PGP SIGNATURE-----