From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ida85-0005nY-L3 for garchives@archives.gentoo.org; Thu, 04 Oct 2007 23:29:18 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l94NJER0030553; Thu, 4 Oct 2007 23:19:14 GMT Received: from mail.genone.homeip.net (dslb-082-083-011-149.pools.arcor-ip.net [82.83.11.149]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id l94NHEuY028148 for ; Thu, 4 Oct 2007 23:17:14 GMT Received: by mail.genone.homeip.net (Postfix, from userid 460) id 397E2281D8; Fri, 5 Oct 2007 01:17:02 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr0-genone_0.7 (2007-02-13) on lyta.genone.homeip.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=7.0 tests=ALL_TRUSTED,BAYES_40 autolearn=ham version=3.1.8-gr0-genone_0.7 Received: from sheridan (sheridan [192.168.0.40]) by mail.genone.homeip.net (Postfix) with SMTP id 6945928089 for ; Fri, 5 Oct 2007 01:16:55 +0200 (CEST) Date: Fri, 5 Oct 2007 01:14:32 +0200 From: Marius Mauch To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] controlling src_test Message-Id: <20071005011432.1f68ee81.genone@gentoo.org> In-Reply-To: References: X-Mailer: Sylpheed 2.4.1 (GTK+ 2.10.11; i686-pc-mingw32) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: f014cee1-3351-461c-9a2b-5c859ce93d6a X-Archives-Hash: 163003ddaeb848a9451c6e2dbc2fe1a2 On Wed, 03 Oct 2007 19:50:01 -0600 Ryan Hill wrote: > There are several packages in portage (and even in base-system) that > fail in src_test when userpriv/usersandbox is enabled or disabled. > That is, some testsuites fail when run as root and some fail if not > run as root. > > I'd like a simple consistent way to mark or handle these packages > without disabling tests altogether (RESTRICT=test). As mentioned > recently, checking ${FEATURES} in an ebuild is frowned upon, and it > doesn't seem right to handle this on a per-ebuild basis. How would > something like this best be implemented? A split up RESTRICT > (test_userpriv/test_nouserpriv)? test.eclass? Something else? > Looking at the bigger picture, are there any other situations where > finer-grained control over the test system would be helpful? See http://bugs.gentoo.org/show_bug.cgi?id=159876 for some suggestions for the "test-only-as-root" case. IMO ebuilds should simply test for the actual capabilities they need in src_test (like uid) instead of more abstract things like userpriv. If such tests can be used in several ebuilds an eclass can help to standardize them, but I don't see a reason to move that logic into the package manager unless those cases are extremely common. As for fine-grained user-control, it's a question of quantification as discussed previously, which isn't easy to solve, or you have to en-/disable things manually and the issue is part tf the per-package-env-variables problem (btw, the /etc/portage/env trick only works because the default src_test in ebuild.sh has the otherwise redundant FEATURES check which was discussed a few days ago in one of the commit reviews) Marius -- gentoo-dev@gentoo.org mailing list