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 72CC4138247 for ; Mon, 20 Jan 2014 19:27:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 56264E0D07; Mon, 20 Jan 2014 19:27:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6F932E0C6B for ; Mon, 20 Jan 2014 19:27:52 +0000 (UTC) Received: from [192.168.11.20] (cpe-72-177-217-176.satx.res.rr.com [72.177.217.176]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steev) by smtp.gentoo.org (Postfix) with ESMTPSA id 4531A33F972 for ; Mon, 20 Jan 2014 19:27:51 +0000 (UTC) Message-ID: <1390245928.14914.6.camel@oswin.hackershack.net> Subject: Re: [gentoo-dev] Re: Add a KEYWORD representing any arch From: Steev Klimaszewski To: gentoo-dev@lists.gentoo.org Date: Mon, 20 Jan 2014 13:25:28 -0600 In-Reply-To: <21211.40692.574361.53989@a1i15.kph.uni-mainz.de> References: <20140114213719.GA2684@laptop.home> <201401190336.10465.vapier@gentoo.org> <1390123713.24148.121.camel@belkin5> <21211.40692.574361.53989@a1i15.kph.uni-mainz.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 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-Transfer-Encoding: 7bit X-Archives-Salt: 1704cfa6-c974-4f2f-bbd8-404b853012dc X-Archives-Hash: a536338471420bd062cc75fdd74a1a0a On Sun, 2014-01-19 at 10:46 +0100, Ulrich Mueller wrote: > Now what problem are we trying to solve? As I see it, it is mainly > one of manpower, namely that some arch teams cannot keep up with > stable requests, and I doubt that any technical solution will help > to solve this. Introducing a "noarch" keyword or allowing "*" will > potentially cause problems with dependency resolution. > > Instead, we should come up with a clear set of rules under what > circumstances package maintainers are allowed to stabilise ebuilds > themselves on all architectures. > When they have machines that cover all architectures - assuming there is some sort of machine code at all. Otherwise, why even bother having stable keywords? Everyone keeps going on about how they will potentially have issues because something old is stable - I've thrown out that maybe we should (after a certain amount of time - when cleaning maybe?) remove all keywords except the only stable one, and then leaving it up to the slow arches. I know what the dev manual says, but I'd much rather have an old ebuild that's KEYWORDS="-* arm" than have that ebuild removed because a new one is KEYWORDS="arm" that doesn't work at all. Everyone else keeps talking in the theoretical, and I'm talking an actual issue. This affects me and my workflow and ask ryao about how he wanted to emerge git-9999 to look into fixing it... -- steev