| 1 |
On Tue, 17 May 2016 13:07:43 +0530 |
| 2 |
Pallav Agarwal <pallavagarwal07@×××××.com> wrote: |
| 3 |
|
| 4 |
> Tests run in src_test are provided by upstream, and does not |
| 5 |
> guarantee that a package that has been merged will actually run on |
| 6 |
> the system. If the maintainer could add a couple small scripts to |
| 7 |
> check basic functionality of the merged package, it would make |
| 8 |
> testing for arch testers much easier and reliable. |
| 9 |
|
| 10 |
Automated post-merge tests sound kinda dangerous to me. And I don't |
| 11 |
think there's any stipulation about src_test() only running |
| 12 |
upstream-provided test suites. IMHO, src_test() would be a good place |
| 13 |
for most of the maintainter-provided tests you have in mind. |
| 14 |
|
| 15 |
Of course, there are some possible tests for which the src_test() |
| 16 |
environment isn't suitable (because they're either interactive or |
| 17 |
really need to run post-merge), I just don't expect there'd be many of |
| 18 |
them. Therefore, I think we'd be better off providing such tests |
| 19 |
out-of-band (test plans in the wiki), or perhaps stuffing them into |
| 20 |
pkg_config(). |
| 21 |
|
| 22 |
Don't get me wrong, I'm not at all opposed to your idea of easing the |
| 23 |
ATs' life, I'm just not convinced of the neccessity of EAPI changes. :) |
| 24 |
|
| 25 |
|
| 26 |
-- |
| 27 |
Regards, |
| 28 |
Luis Ressel |
| 29 |
|
| 30 |
Luis Ressel <aranea@×××××.de> |
| 31 |
GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD |
Archives