On Thursday 04 October 2007 09:36:29 Doug Goldstein wrote:
> 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?

I think most everybody agrees that boost's tests are overly comprehensive. As 
for others like mysql,  a long test may be necessary to ensure everything is 
working properly.

-- 
2.6.22-gentoo-r8