User:Kentnl/FEATURES=test enhancements

From Gentoo Wiki
Jump to:navigation Jump to:search

Following are a list of reasons I think we should abolish the hack of

FEATURES="test" -> USE="test"

And Have a "real" Test dependencies scheme.

Test Phase Only USE dependencies

I'm frequently seeing patterns where there are different kinds of tests that can be run and many of them require "optional" dependencies.

Gentoo standard dogma is to either never pull optional dependencies, or always pull optional dependencies

For tests, this is very sub par.

Some packages for instance may contain reverse-dependency regression tests, that is:

  • Consider a library "foo".
  • "foo" uses "bar"
  • "bar" wants to make sure nothing they change breaks "foo"
  • so "bar" contains a test ( or set of tests ) where those tests call "bar" and run it against "foo" in specific ways.
  • So under "normal" conditions, foo -> bar
  • But under test conditions, if the reverse tests are to be run, bar -> foo ( because "bar" could be installed independently for some other thing before "foo" gets installed )
  • ERROR: Circular Deps if you're lucky.
  • Workaround: USE="regression-tests" ( off by default, encouraged to be on for testers )

Here, this ends up creating a spurious USE flag that is seen in every emerge -v output, despite the fact toggling that flag without FEATURES=test can never have any effect.

Subsequently, it would be nice if there could be a mechanism to hide useflags that are dependent upon FEATURES=test being enabled.

Opportunity to have USE_EXPAND TEST:

In conjunction with the ability to hide use-flags that are only relevant under FEATURES=test, it also allows better test-specific flag naming via USE_EXPAND.

 dev-foo/bar examples cgi ruby perl  TESTS: regression network


Cycle-Breaking multi-pass for tests

This currently creates a cycle:

  A rdep B
  B tdep A

This can be reordered as follows:

  Install B [-test]
  Install A
  Install B [+test]

If done carefully, the build state of "B" could be preserved, and so it would break further down as

  Compile B
  [deferred] Test B
  Install B
  Compile A
  Test A
  Install A
  [undefer] Test B

Though Ideally, you'd probably want a way to avoid installing either A or B until B's tests have passed:

  Compile B
  Soft-Install B
  Compile A
  Test A
  Soft-Install A
  Test B
  Commit B
  Commit A

Though this probably requires a lot of hand-holding.