Return to pkgsrc-test-depends.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / projects / project

Annotation of wikisrc/projects/project/pkgsrc-test-depends.mdwn, revision 1.2

1.1       dholland    1: [[!template id=project
                      2: 
                      3: title="Separate test depends for pkgsrc"
                      4: 
                      5: contact="""
                      6: [tech-pkg](mailto:tech-pkg@NetBSD.org)
                      7: """
                      8: 
                      9: category="pkgsrc"
                     10: difficulty="medium"
                     11: duration="3-6 weeks"
1.2     ! wiki       12: done_by="joerg"
1.1       dholland   13: 
                     14: description="""
                     15: 
                     16: Right now the pkgsrc packaging for many things does not support
                     17: running those things' native test suites.
                     18: One of the reasons for this is that those test suites often depend on
                     19: additional packages for test infrastructure or test automation.
                     20: Sometimes those additional depends cause cycles; sometimes they're
                     21: "only" heavyweight; but fairly often adding them as unconditional
                     22: BUILD_DEPENDS (or worse, full DEPENDS) has undesirable consequences.
                     23: 
                     24: It ought to be possible to have a separate set of TEST_DEPENDS that's
                     25: brought in only when one is actually intending to run a test suite.
                     26: This is not entirely trivial (or it would have been done long ago)
                     27: because it doesn't fit well into the sequence of phases pkgsrc builds
                     28: happen in.
                     29: Should there be a separate (and late) phase for TEST_DEPENDS, or a
                     30: (per-package?) switch in mk.conf to enable test material, or some
                     31: other scheme?
                     32: What about packages that need to be installed first before their tests
                     33: will run?
                     34: (Yes, ideally these wouldn't exist...)
                     35: 
                     36: The first part of this project is: decide how it should work and sell
                     37: the community on it, er, I mean, reach consensus with the community on
                     38: the best approach.
                     39: This (including sorting through all the requirements and miscellaneous
                     40: desiderata, which are by no means listed completely above) is at least
                     41: half the work.
                     42: 
                     43: The second part of this project is to implement what you've designed,
                     44: and add support to three or four packages with nontrivial test suites.
                     45: 
                     46: (Note: this project description was partly based on loose talk on the
                     47: subject appearing in PR 50645.)
                     48: 
                     49: """
                     50: ]]