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?
While I'm on the subject, I also thought it would be cool to have the option to
not die on a src_test failure, but instead to dump the log file and continue
on to the install phase. I know this can be done per-ebuild, but it'd be
a useful global option.
--
fonts / wxWindows / gcc-porting / treecleaners
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
--
[EMAIL PROTECTED] mailing list
