-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
>
> 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.
>
I, for one, would like to be able to control whether or not to run tests
that take a huge amount of time to run. Some test suites are
ridiculously comprehensive, and if we could have an option to disable
only those, or even run a reduced test suite, that'd be pretty neat.
- --Ravi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBI2JsDgfoknqAqMRAj7+AKDY1wJYClm13wmxMWxgGxCfqzlfOwCgl2tT
qXwJ8Cz5HL+W1ois4IRzvOw=
=CjAo
-----END PGP SIGNATURE-----
--
[EMAIL PROTECTED] mailing list
