Ravi Pinjala wrote:
> 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
>
Who and what determines if a test is overly comprehensive and takes too
long to run?
--
[EMAIL PROTECTED] mailing list
