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.43) id 1EGN6i-0008S5-Ay for garchives@archives.gentoo.org; Fri, 16 Sep 2005 20:46:52 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j8GKeVwT012945; Fri, 16 Sep 2005 20:40:31 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j8GKcH2b027580 for ; Fri, 16 Sep 2005 20:38:18 GMT Received: from localhost ([127.0.0.1] helo=home.wh0rd.org) by smtp.gentoo.org with esmtp (Exim 4.43) id 1EGN3N-00012H-DE for gentoo-dev@lists.gentoo.org; Fri, 16 Sep 2005 20:43:25 +0000 Received: (qmail 14044 invoked from network); 16 Sep 2005 16:39:27 -0400 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 16 Sep 2005 16:39:27 -0400 From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] first council meeting Date: Fri, 16 Sep 2005 16:43:36 -0400 User-Agent: KMail/1.8.2 References: <20050915205149.GB22270@vino.zko.hp.com> <20050916202159.GF16616@olive.flatmonk> <1126902358.9857.6.camel@Memoria.anyarch.net> In-Reply-To: <1126902358.9857.6.camel@Memoria.anyarch.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509161643.36591.vapier@gentoo.org> X-Archives-Salt: 21c71b12-fcfc-44b1-aadd-02f9126f0edc X-Archives-Hash: 135df231af817a86f13f69a81bc9e389 On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote: > His point (and it's an unfortunately valid one) as I understand it is > that our user base has been (mis)educated to avoid packages in p.mask > for fear of breaking things too badly. As such it gets an inherently far > smaller test base then packages in ~arch do. i [rightly] fear package.mask packages most of the time. we stick things in there that have security issues, or are known to be badly broken in some way, or wont work in subprofiles for archs (think glibc-specific packages masked in a uclibc profile). at the sametime, we use package.mask for things that *should* work fine, but we dont know yet. i wouldnt mind a restricted 4th level of masking here: arch stable ~arch unstable ?arch should work fine, but not 100% sure yet package.mask known to be broken in some way it's also a pita to maintain package.mask since we're storing information about specific ebuilds outside of the ebuild itself, and it tends to suffer badly from bitrot -mike -- gentoo-dev@gentoo.org mailing list