On Friday 13 April 2007, Daniel Ostrow wrote: > 1). Even though src_test is not mandatory in the here and now any > package that provides a test suite that fails said tests has a bug. It > may not be a critical bug but it is in fact a bug. > > 2). The proper fix, again in the here and now, for said bug is either to > a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since > sec_test is not mandatory however these things happen rarely if at all. > > With the above in mind I entirely agree that adding it as a mandatory > phase for EAPI=1 makes sense. Think of it this way: > > 1). Developer A is bumping a package and is including some new > functionality in his ebuilds that require something in EAPI=1, say for > example a SLOT dependency. As such Developer A is already editing the > ebuild *and* testing it. > > 2). As part of his test he checks if the built in test suite works, > something he should be doing *anyway*. If it does great, if it doesn't > then he has two choices, as above, fix it or add a RESTRICT="test", at > *worst* adding 15 whole characters (16 if you include the extra carriage > return he will need to add) to his ebuild. > > 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to > bigger and better things. > > This will allow a whole slew of VERY useful information to be available: > > 1). The QA team can now query the tree for packages that have known bad > test suites simply by looking for ebuilds that have RESTRICT="test". As > it stands now this is impossible to accomplish. > > 2). Interested volunteers, both developer and user alike, who are > looking for ways to help out, can now be given a concrete list of known > test suites to go and fix, this improves the QA of the packages in the > tree. > > 3). The fact that a bug in the test suite exists is no longer hidden > from view. > > 4). Since the test suites are now mandatory end users can feel more > confident in the state of their installed software, this is no silver > bullet but it is a step in the right direction. > > The *only* downside that I can see here is that by default the package > installation process gets a little longer. To get around this some > method of globally opting out of src_test should be provided to the end > user, however since it is an on by default feature someone at least has > *tried* the test suite.
so you've validated that the platform the developer testing the ebuild on works ... you know nothing about any other platform that Gentoo supports and in the end, the users continue to hit src_test failure after src_test failure which, after they quickly get tired of filing [duplicate] bugs, they realize they have no way at all of disabling the mandatory test ... RESTRICT is an ebuild variable, not a package manager variable as you said yourself, it may not be a critical bug, but it's still a bug and users have no way of trivially bypassing it or even opting out of tests in the first place. you may enjoy running src_test on every single machine of yours out there, but i certainly dont. this is why implementing it via the profile FEATURES works ... users can still easily opt out and in case of some catastrofuck and we havent screwed ourselves into a corner by mixing policy with spec -mike
pgpks5ACl0q1j.pgp
Description: PGP signature
