From: Thomas Anderson <gentoofan23@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] controlling src_test
Date: Thu, 4 Oct 2007 10:36:33 -0400 [thread overview]
Message-ID: <200710041036.38342.gentoofan23@gmail.com> (raw)
In-Reply-To: <4704EC5D.9070304@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-04 14:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 1:50 [gentoo-dev] controlling src_test Ryan Hill
2007-10-04 6:51 ` Ravi Pinjala
2007-10-04 13:36 ` Doug Goldstein
2007-10-04 14:36 ` Thomas Anderson [this message]
2007-10-04 14:51 ` Rémi Cardona
2007-10-04 17:39 ` [gentoo-dev] " Ryan Hill
2007-10-04 19:47 ` Ryan Hill
2007-10-04 21:10 ` Chris Gianelloni
2007-10-04 21:18 ` Rémi Cardona
2007-10-05 1:34 ` Ryan Hill
2007-10-04 20:31 ` Alin Năstac
2007-10-04 21:16 ` Ryan Hill
2007-10-04 23:14 ` [gentoo-dev] " Marius Mauch
2007-10-04 23:32 ` Bo Ørsted Andresen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200710041036.38342.gentoofan23@gmail.com \
--to=gentoofan23@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox