From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FEBje-0000CE-Kh for garchives@archives.gentoo.org; Tue, 28 Feb 2006 20:46:19 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1SKhxi7019874; Tue, 28 Feb 2006 20:43:59 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1SKcYd3027725 for <gentoo-dev@lists.gentoo.org>; Tue, 28 Feb 2006 20:38:35 GMT Received: from localhost ([127.0.0.1] helo=home.wh0rd.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1FEBcs-0007AG-TU for gentoo-dev@lists.gentoo.org; Tue, 28 Feb 2006 20:39:19 +0000 Received: (qmail 15378 invoked from network); 28 Feb 2006 15:35:50 -0500 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 28 Feb 2006 15:35:50 -0500 From: Mike Frysinger <vapier@gentoo.org> Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role Date: Tue, 28 Feb 2006 15:39:43 -0500 User-Agent: KMail/1.9.1 References: <20060227213321.7ee405ec@snowdrop.home> <200602281459.42324.vapier@gentoo.org> <904604312.20060228211037@gentoo.org> In-Reply-To: <904604312.20060228211037@gentoo.org> GEOMAN: IS A RETARD Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602281539.43661.vapier@gentoo.org> X-Archives-Salt: 4983265e-cd88-43c2-b6a7-d25d32401df3 X-Archives-Hash: d923fcf63110d82546a17f66bd29f682 On Tuesday 28 February 2006 15:10, Jakub Moc wrote: > 28.2.2006, 20:59:42, Mike Frysinger wrote: > > On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: > >> On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote: > >> > And it sticks out a nasty ewarn and says that the ebuild is probably > >> > broken. > >> > >> Which it _probably_ is. See, this is a numbers game. In most cases, if > >> you use the webapp eclass, setting SLOT="0" is incorrect. There are some > >> cases in which it's just fine. Until FEATURES="mindreader" is > >> implemented, how is the eclass to know what you're trying to do? So it > >> prints a warning and doesn't die. Number of angry users storming > >> bugs.g.o - 0. > > > > why do you need to be a mindreader ? the user requested they control the > > package, thus it isnt a bug, so dont issue a warning > > Sure, and when *ebuild* requested it instead, then portage will be > automagically informed. So yeah, we can implement yet another variable into > the eclass, and we can do tons of other magic voodoo about three lines of > eclass that noone has ever noticed until today, and the whole thing can be > a lot more complex for sure. Sorry, I call this a complete waste of time. whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap -mike -- gentoo-dev@gentoo.org mailing list