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 D5CA713877A for ; 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 ; Sun, 27 Jul 2014 10:43:58 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id j15so6341604qaq.25 for ; 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: 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.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: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> Date: Sun, 27 Jul 2014 22:43:57 +1200 Message-ID: Subject: Re: [gentoo-dev] Re: don't rely on dynamic deps From: Kent Fredric 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 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

= 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 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.

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>
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.

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.

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 ).

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.

-r bumping is of course *a* way to tra= nsmit the data.

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*.

--
--001a1133d5f6ce7a1a04ff2a7ba9--