From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-66963-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 D5CA713877A
for <garchives@archives.gentoo.org>; Sun, 27 Jul 2014 10:44:03 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 77949E0DFB;
Sun, 27 Jul 2014 10:43:59 +0000 (UTC)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 8413CE0DD3
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jul 2014 10:43:58 +0000 (UTC)
Received: by mail-qa0-f52.google.com with SMTP id j15so6341604qaq.25
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jul 2014 03:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=ZNFoJMuDCrLOb/EczOdCHNK2KJW3z9xTKPDzyyapsAA=;
b=QQDCtPDmH1vinPiV+SIogj5y/NFeJCHqnQxOKsZeB2EKztAL5+ssTgdtQud+HOwbxv
0ZY2JY5fyJc2sV9dDBDkXtstlJZppe2Cg4utGT78/jat86RLfurJXKlTS+NKpav2EIfX
CMoGhBqvUizJn77nOBwFbftnbSGFWbBfpbKRSIEV9xKSkHviTPLFdx4RX21h3BjCoPwg
jOyzpqDmiJpPJ6u8QKB5h1vTdD2Eibb4uCFnxZxmEW1/muh7qsVg4IAp6WbYjEpHOcYc
x/uhGr9eWyPxdGTmBlsha5aU/GYyQQIkxlKxa11Dd6s8cTLQp8Q1iCQczIqU1DreyT7T
Hf2A==
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.224.87.130 with SMTP id w2mr46726938qal.5.1406457837679;
Sun, 27 Jul 2014 03:43:57 -0700 (PDT)
Received: by 10.140.44.34 with HTTP; Sun, 27 Jul 2014 03:43:57 -0700 (PDT)
In-Reply-To: <slrnlt99qe.fl1.martin@epidot.math.uni-rostock.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>
Date: Sun, 27 Jul 2014 22:43:57 +1200
Message-ID: <CAATnKFAq99S8etuHHVBj0MLvQ5tMLSu-xCcnReytAccwHPXFRQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: don't rely on dynamic deps
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=001a1133d5f6ce7a1a04ff2a7ba9
X-Archives-Salt: bef4c5a4-c632-4d98-9bd4-912962b269ad
X-Archives-Hash: 133b9ddc9a75151118dd62cdefbdd383
--001a1133d5f6ce7a1a04ff2a7ba9
Content-Type: text/plain; charset=UTF-8
On 27 July 2014 19:16, Martin Vaeth <martin@mvath.de> wrote:
> Not at all, it is completely identical to a revision bump:
> If you would use -r2 instead of -r1.1, you also would end up
> in -r1 and -r2 being identical.
> Actually, in both cases, you would *remove* -r1, since -r1 is incorrect
> since it should have been bumped.
>
>
It just seems strange to me to go round a large tree and bump every ebuild
affected by an eclass change, simply not modifiying the code, buy changing
the -r value on the end of it.
In a "no dynamic deps, period" scenario, this just strikes me as 2 flavours
of the same weirdness, -r2 and -r1.1 are just equally weird choices to make
if the ebuild itself doesn't change at all.
For some things it would be a nightmare of impossibility for even a trivial
change if some eclass changed to have one new dependency/one less
dependency. You'd need some system in place to go around the tree -r
bumping things, and the system would involve humans who are prone to making
mistakes, and create commit churn to make it happen.
The same problem would still persist with people forgetting to -r bump, or
missing one ebuild in the ~200 affected, but with dynamic deps off, those
bugs would lie in wait and confuse portage until somebody filed a bug and
it got responded to.
Sure, having an approved system to ship dependency-only changes to the end
users tree is something we do need, I'll grant that, but the point of
failure is already significantly weighing on developer time, and this would
see a growth in developer time to manage this ( I could be over estimating
how much, but -r bumping everything that used a specific eclass is
something I very much do not envy ).
However, if there was a system in place such that developers didn't have to
manually do any -r bumping , but "some system" acknowledge the changes and
scheduled some kind of VDB update in response to some kind of data that was
transmitted as part of the sync, that would be nice.
-r bumping is of course *a* way to transmit the data.
Just I feel strongly inclined that we shouldn't be making developers expend
*more* effort to solve this problem if there's a way we can make them spend
*less*.
--
Kent
*KENTNL* - https://metacpan.org/author/KENTNL
--001a1133d5f6ce7a1a04ff2a7ba9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 27 July 2014 19:16, Martin Vaeth <span dir=3D"ltr"><<a href=3D"mailto=
:martin@mvath.de" target=3D"_blank">martin@mvath.de</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div id=3D":39u" class=3D"a3s" style=3D"overflow:hidden">Not at all, it is =
completely identical to a revision bump:<br>
If you would use -r2 instead of -r1.1, you also would end up<br>
in -r1 and -r2 being identical.<br>
Actually, in both cases, you would *remove* -r1, since -r1 is incorrect<br>
since it should have been bumped.<br>
<div class=3D""><br></div></div></blockquote><div><br></div><div>It just se=
ems strange to me to go round a large tree and bump every ebuild affected b=
y an eclass change, simply not modifiying the code, buy changing the -r val=
ue on the end of it. <br>
<br></div><div>In a "no dynamic deps, period" scenario, this just=
strikes me as 2 flavours of the same weirdness, -r2 and -r1.1 are just equ=
ally weird choices to make if the ebuild itself doesn't change at all.<=
br>
<br></div><div>For some things it would be a nightmare of impossibility for=
even a trivial change if some eclass changed to have one new dependency/on=
e less dependency. You'd need some system in place to go around the tre=
e -r=C2=A0 bumping things, and the system would involve humans who are pron=
e to making mistakes, and create commit churn to make it happen.<br>
<br></div><div>The same problem would still persist with people forgetting =
to -r bump, or missing one ebuild in the ~200 affected, but with dynamic de=
ps off, those bugs would lie in wait and confuse portage until somebody fil=
ed a bug and it got responded to.<br>
</div><br></div><div class=3D"gmail_quote">Sure, having an approved system =
to ship dependency-only changes to the end users tree is something we do ne=
ed, I'll grant that, but the point of failure is already significantly =
weighing on developer time, and this would see a growth in developer time t=
o manage this ( I could be over estimating how much, but -r bumping everyth=
ing that used a specific eclass is something I very much do not envy ).<br>
<br></div><div class=3D"gmail_quote">However, if there was a system in plac=
e such that developers didn't have to manually do any -r bumping , but =
"some system" acknowledge the changes and scheduled some kind of =
VDB update in response to some kind of data that was transmitted as part of=
the sync, that would be nice.<br>
<br></div><div class=3D"gmail_quote">-r bumping is of course *a* way to tra=
nsmit the data.<br><br></div>Just I feel strongly inclined that we shouldn&=
#39;t be making developers expend *more* effort to solve this problem if th=
ere's a way we can make them spend *less*.<br>
<br></div><div class=3D"gmail_extra">-- <br><div dir=3D"ltr"><div>Kent<font=
size=3D"1"><b> <br><br></b></font></div><div><span style=3D"color:rgb(204,=
204,204)"><font size=3D"1"><b>KENTNL</b> - <a href=3D"https://metacpan.org/=
author/KENTNL" target=3D"_blank">https://metacpan.org/author/KENTNL</a></fo=
nt></span><br>
</div><div><br></div></div>
</div></div>
--001a1133d5f6ce7a1a04ff2a7ba9--