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 5B7761391DB for ; Sun, 27 Jul 2014 12:19:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5FDE0E0EE7; Sun, 27 Jul 2014 12:19:09 +0000 (UTC) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6D88AE0D43 for ; Sun, 27 Jul 2014 12:19:08 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ik5so1071535vcb.34 for ; Sun, 27 Jul 2014 05:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Nv0PGoaM5oVpDGHF9JmPYeRuNH9OrBW9Z5kV6wUjeas=; b=yItxlrbq/GNhd6mp5Zp68fjbx/7uZyudRzSiQsdXan7xJW7rVzby6i6rrZ89esr68s 1PatdtH4UZmt7H7DFQMbOO3jQW6zxUlDTbM+CUtOkmSIweGPbbY0yWvjSG9sZbS1IZxI 3mUZP+gscboQkMWC4XEYLkOiyvuidBVDikaFvvL98486L+lXp/TS4IQWXSq0/Fk2Ilu7 Cd3PLFspcI+rvpe4J++Erxq9ckaT6FKL+pOPjzkRhPwnd527OQIVFfhyNPcWSzjANST3 Mmh88Ws9boZ19aVsqESJny2qOcRz3OF5GU+RvMjzQ+77nsFtWtfvoU9EFoNswDhyqARZ fuIg== 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 X-Received: by 10.221.59.194 with SMTP id wp2mr4855326vcb.59.1406463547608; Sun, 27 Jul 2014 05:19:07 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Sun, 27 Jul 2014 05:19:07 -0700 (PDT) In-Reply-To: <21460.53636.443757.372244@a1i15.kph.uni-mainz.de> References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> <21460.53636.443757.372244@a1i15.kph.uni-mainz.de> Date: Sun, 27 Jul 2014 08:19:07 -0400 X-Google-Sender-Auth: nX1QPZgx3YDyHzcZL_Gh5f2tYYY Message-ID: Subject: Re: [gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps) From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 0dc8bfa2-4e63-4874-bfbc-3dd9122b6ae5 X-Archives-Hash: 5a97d97c11078aa39bcb2a96e98e6b17 On Sun, Jul 27, 2014 at 6:16 AM, Ulrich Mueller wrote: > 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. This isn't all that different from the concept I put out around having the PM cache hashes of last-seen ebuilds, except that the hash is editable so that developers can mess with it this way, allowing revbumps to avoid rebuilds. If an eclass/virtual/etc change impacted 200 packages, would you then revbump all of them but setting INSTALL_VERSION on all the bumps? That could involve a lot of ebuild munging. Also, if you add hard-coded INSTALL_VERSIONs to ebuilds that lacked them previously, maintainers would have to notice that and remove those the next time they did a bump or even a non-revbump might not trigger a rebuild since it is still pointing to the old minor revision. I take it that we would also have the package manager not do dynamic deps if the revision doesn't change if we used the INSTALL_VERSION approach? This scenario still beg's Kent's question, "why do we have to point out to portage that the deps need reparsing?" If we're going to have dynamic deps, then shouldn't reparsing deps be the default when they change, and rebuilds should be the fallback when a big change happens that dynamic deps can't handle? If so, then we already have a mechanism for that - you change the revision when you want a rebuild, and then this just comes down to devs revbumping when they need to, and having the PM able to detect other changes and properly handle them. And yes, I know the argument is that some changes can never be properly handled, but my point is that we only use dyanmic deps for changes which can be handled properly, so we're just arguing over whether that is the empty set or not. Rich