From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-67054-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 0FAB713877A
for <garchives@archives.gentoo.org>; Mon, 28 Jul 2014 18:35:46 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 6FFC4E0D73;
Mon, 28 Jul 2014 18:35:41 +0000 (UTC)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 95273E0D10
for <gentoo-dev@lists.gentoo.org>; Mon, 28 Jul 2014 18:35:40 +0000 (UTC)
Received: by mail-vc0-f180.google.com with SMTP id ij19so11587717vcb.25
for <gentoo-dev@lists.gentoo.org>; Mon, 28 Jul 2014 11:35:39 -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=sgrJ6pfslJJPgxliNDGKbTDqkvuc2WeMdHSK73lfWuY=;
b=xnlB9eny6R6IOcvpz8EhNZWlzwcAUCwETybY3UPtlYaMKTaL8ofk1uHQ0a845c323u
D+CLegGeJ3nBrnZnTdvj203zZCVO/SaeLAXDy2+SyLhihm4lEX/Fh0ZtSF5F54lQbI9k
YvBT1yv6USpeM39MpVilLe+vbNg+XyWnIJXLt8cTfOSnXa1qzLO5MNpTUYy0Tc5Rn/az
evE9wo55FjeZzeuE2QosjzoWUIC5ndkJsqWmbk9bPgX79fNFCzf18UBLBmOCLeJDmhgb
KqBetHquubuhtOjorL8iidBEhKZOB9sUnC3UgP7F/Bh2/nci54vFWGeuA9AjIcsHmddE
rgMQ==
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.52.248.146 with SMTP id ym18mr40051867vdc.8.1406572539687;
Mon, 28 Jul 2014 11:35:39 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.8.229 with HTTP; Mon, 28 Jul 2014 11:35:39 -0700 (PDT)
In-Reply-To: <53D695F6.7050302@gentoo.org>
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>
<CAATnKFAq99S8etuHHVBj0MLvQ5tMLSu-xCcnReytAccwHPXFRQ@mail.gmail.com>
<CAGfcS_mOw6eASvApJpAy7+C1QSi3ZE6akR-JZ4B=L6VDbSgjMw@mail.gmail.com>
<53D695F6.7050302@gentoo.org>
Date: Mon, 28 Jul 2014 14:35:39 -0400
X-Google-Sender-Auth: PmK1ogmnPUo1Tzuln9BYTdCVVvQ
Message-ID: <CAGfcS_mcG7wmt++Pq3nahAM5Pokx=nBaivqzZ-9EmLY6hqx8xA@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: 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: a3d6b8d4-39c1-4ba2-a7cd-7d63b7b691f5
X-Archives-Hash: b91eb2bfe425192b4fb16826ef6f631f
On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> The primary underlying problem I see about this is that it doesn't
> force devs to start doing something to the tree that will suddenly
> help make all of the static-deps-only PMs (ie, those that aren't going
> to implement this new hash-changed-so-re-evaluate-ebuild method)
> suddenly work in a more consistent fashion. IIRC, the very first post
> of this thread was a reminder to dev's to revbump so that static-deps
> behaviour is more correct/consistent.
I think the intent here is to define how we want the PM to behave, and
what kinds of changes should require revbumps (ie those the PM can't
handle otherwise).
Obvious a side-effect of this will be that PMs that don't behave as we
intend them to may have issues.
>
> However, if we put something into the next EAPI about this and make it
> a requirement for all PMs (although I have no idea how we would roll
> this out; maybe make it a profile-level requirement instead of an
> ebuild-level one, if there is such a thing??)
It may make sense to do this via a new EAPI, though I think figuring
out what we want to do comes first. That is, I want to ask the
question "if no PMs existed and we were writing our first one, how
would we want it to behave?" Getting from here to there is the next
problem.
Really the issue comes down to how we maintain ebuilds. If we aren't
revbumping for dependency errors, then PMs that don't handle dynamic
deps wouldn't update their dependencies. That certainly has
consequences, but whether they're considered "bugs/problems/etc" is a
bit up for debate.
I'm not convinced that it makes sense to do "micro-revbumps" just to
force PMs that don't have any concept of dynamic dependencies to treat
them as full revbumps. Devs can still forget to do them, and it
results in churn that doesn't seem necessary to me. On the other hand
I don't want to make life even more difficult on those using
alternative PMs (though it sounds like we're doing this already).
It seems like we aren't getting many more new options here.
Rich