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 32E5D13877A for ; Mon, 28 Jul 2014 15:16:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CADA0E0C85; Mon, 28 Jul 2014 15:16:31 +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 E357BE0C7A for ; Mon, 28 Jul 2014 15:16:30 +0000 (UTC) Received: from big_daddy.dol-sen.ca (S010600222de111ff.vc.shawcable.net [96.49.5.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id CAD1833FFBB for ; Mon, 28 Jul 2014 15:16:29 +0000 (UTC) Date: Mon, 28 Jul 2014 08:15:37 -0700 From: Brian Dolbec To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Avoiding rebuilds Message-ID: <20140728081537.2f8a8199.dolsen@gentoo.org> In-Reply-To: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> <21460.53636.443757.372244@a1i15.kph.uni-mainz.de> <53D5027E.7060808@gentoo.org> Organization: Gentoo 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 0997b67f-d983-4e38-a8dc-b0e0ecec0a98 X-Archives-Hash: 4025e488368cf95b5c49e71b5e1112a1 On Mon, 28 Jul 2014 05:49:07 +0000 (UTC) Martin Vaeth wrote: > hasufell wrote: > > Ulrich Mueller: > >> > >> I wonder if it wouldn't be saner to leave our revision syntax > >> untouched. > > As already mentioned, -r1.1 is only one of several possible ways > how to achieve the same aim; I am not speaking in favour for a > particular method. > The -r1.1 method has the advantage of being simple and transparent > to the user and developer. Other approaches have other advantages: > > >> Instead, one could introduce a variable INSTALL_VERSION that would > > (It would have to be a variable stored in the metadata/ cache > and thus also would only work with a new API, but these are only > technical details.) > > >> default to ${PVR} but could be set to the version of a previous > >> ebuild instead. The PM could compare it against INSTALL_VERSION in > >> the VDB and skip build and installation if versions match. > > It should be a list and have empty default (*never* including the > version itself), but these are also technical details. > This solution would have the advantage that you could specify > *full* versions and thus have even more fine-grained control when > recompilations are necessary. One could also allow specify version > ranges, slots, overlays, etc., perhaps even make the behaviour > dependent of USE-flags, as you already mentioned, all > similarl to current DEPEND syntax. > > The disadvantage is that it is slightly more work than -r1.1, > less transparent, and easily overlooked to remove for a version bump, > causing issues like these: > > > It will probably also cause confusion for comaintainers and > > collaborators, especially when INSTALL_VERSION points to a version > > that has already been removed. > > I haven't had the energy to read all the mails over all the dynamic deps thread... the -r1.1 syntax has been in use by the prefix since early in it's existence. I haven't kept track, but they may have finally done away with it. There are many other problems with using that syntax, namely most other tools are not compatible with it, so more than just portage needs to be modified. Adding that syntax to ebuilds will cause disruptions and bugs for years to come. So, please, forget about this syntax as a viable solution. -- Brian Dolbec