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 7907E1391DB for ; Sun, 27 Jul 2014 13:45:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B73C6E0C48; Sun, 27 Jul 2014 13:45:43 +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 D3C2DE0BFC for ; Sun, 27 Jul 2014 13:45:42 +0000 (UTC) Received: from 127.0.0.1 (tor21.anonymizer.ccc.de [31.172.30.4]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 5917533FFEE for ; Sun, 27 Jul 2014 13:45:41 +0000 (UTC) Message-ID: <53D5027E.7060808@gentoo.org> Date: Sun, 27 Jul 2014 13:45:34 +0000 From: hasufell 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] Avoiding rebuilds References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> <21460.53636.443757.372244@a1i15.kph.uni-mainz.de> In-Reply-To: <21460.53636.443757.372244@a1i15.kph.uni-mainz.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 464729a1-6d55-45b9-8c2d-707adece95d8 X-Archives-Hash: b6adfe3ffd2d9db641b91214be168fe0 Ulrich Mueller: >>>>>> On Sun, 27 Jul 2014, Martin Vaeth wrote: > >> Kent Fredric wrote: >>> -r1.1 weirdness feels like it may cause more problems than it solves. > >> So far, nobody pointed out any problem which would be caused by -r1.1. >> Which is not surprising, since the idea is that -r1.1 cannot be >> distinguished from -r2: >> It is only a hint to the PM that he *may* shortcut certain phases when >> updating from -r1. > > I wonder if it wouldn't be saner to leave our revision syntax > untouched. > > Instead, one could introduce a variable INSTALL_VERSION that would > 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. > > Advantages: > - Support for the variable could be optional. PMs not supporting it > would do a regular revbump instead. > - One could even imagine USE-conditional syntax for the variable. > Aren't we putting a lot of trust in ebuild writers here? If any, I'd say this should definitely be an optional feature for portage as well and default to off. The only time I would really consider using this would be for the very few time-intensive packages I maintain like paraview, rstudio or blender. For the rest, it's too much effort. It will probably also cause confusion for comaintainers and collaborators, especially when INSTALL_VERSION points to a version that has already been removed.