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 C1AD8138CE3 for ; Mon, 10 Feb 2014 14:53:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 07D1EE0B9D; Mon, 10 Feb 2014 14:52:12 +0000 (UTC) Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be [195.130.132.51]) by pigeon.gentoo.org (Postfix) with ESMTP id 09C5CE0B96 for ; Mon, 10 Feb 2014 14:52:10 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by baptiste.telenet-ops.be with bizsmtp id QesA1n0082khLEN01esAFt; Mon, 10 Feb 2014 15:52:10 +0100 Date: Mon, 10 Feb 2014 15:52:08 +0100 From: Tom Wijsman To: rich0@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Tightening EAPI rules Message-ID: <20140210155208.5e2fc095@TOMWIJ-GENTOO> In-Reply-To: References: <52F8C97D.4030403@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 15d96449-ba49-415c-b495-ef0720ce9f0c X-Archives-Hash: 345dee49d761a08261fedf374f5de2b5 On Mon, 10 Feb 2014 08:34:00 -0500 Rich Freeman wrote: > On Mon, Feb 10, 2014 at 7:43 AM, Patrick Lauer > wrote: > > Adding EAPI 1 and 2 ebuilds is forbidden. (repoman-fatal) > > Does "adding" in this case include revbumps? Yes; though, we kind of expect rev bumps to include multiple fixes if possible, not just a fix for a particular bug. It is indeed kind of up to the maintainer if he wants to include trivial fixes like EAPI bumps and what not; though, it can be really fun when you add patches to src_prepare in an EAPI that doesn't support src_prepare yet... :) > > More than two supported EAPIs is an unneeded burden on developers. > > Is this really a generally held belief? I don't find it a burden that > ebuilds in the tree may use various EAPIs. I could see how they make > scripted mass-updates to ebuilds more difficult, though I'm not sure > how much of an issue this is in practice. > > I could also see how supporting many EAPIs could be a burden on > package managers, but if that is a concern I'd be interested in > hearing from these maintainers. > > My sense is that deprecating probably makes sense, but banning should > only be done if in reaction to a particular problem. Repoman warnings > call attention to the issue so that the maintainer is aware and can > take the appropriate action, but without restricting their actions. > > Now, if people are actually impacted by all the EAPIs I don't mind > pushing harder to get rid of some. A lot of this is more of a future proof approach than to address an actual practical problem; the ~5 or so cases we've got to support in PMs, which are actually often just ~2 or ~3, aren't really a burden as it stands now. But once that gets to the ~10 cases, which boils down to often like maybe ~4 to ~6 cases; it becomes a bit more bloated up to a point you really start yelling at code cruft, but we're still far from as there are less often PMS releases these days. Well, some of us also see it as code cruft in the Portage tree; also in a way that is growing as we get more releases of the PMS, this will probably not ever really bother maintainers (unless we expect them to know how older EAPIs were by heart, this is comparable to how web developers need to account for older versions of browsers) but it really could start to bother those whom look over the whole Portage tree. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D