From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-66974-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 5B7761391DB
for <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; Sun, 27 Jul 2014 12:19:08 +0000 (UTC)
Received: by mail-vc0-f175.google.com with SMTP id ik5so1071535vcb.34
for <gentoo-dev@lists.gentoo.org>; 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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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>
<CAATnKFAXWLdTxZw42GZL3HoukL_x1hfwzRsOY6zfj03i5eJCTw@mail.gmail.com>
<slrnlt7dq8.9i1.martin@epidot.math.uni-rostock.de>
<CAATnKFCVM3=otkhja=Gp+vq+DJpLSYsgFtgfAmkP=cdUeiQQrw@mail.gmail.com>
<slrnlt99qe.fl1.martin@epidot.math.uni-rostock.de>
<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: <CAGfcS_=+eRpsWjv0zCdr22NJ3SyyhJoALV0JmTOYMokoTCQ4WQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps)
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
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 <ulm@gentoo.org> 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