On Wed, 03 Oct 2007 19:50:01 -0600
Ryan Hill <[EMAIL PROTECTED]> 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
--
[EMAIL PROTECTED] mailing list
