Good morning, Andreas (and also all who reads this letter)!
First part of this letter is just to inform you, but I also have several questions about packaging with perl for RostLab packages (questions are given at the end of this letter).
0) First of all, this is what I did for now:
* Concavity, Conservation-code, Dssp - these packages you already saw.
* Tm-align - I made 1 test for both programs in it (TMscore and TMalign), added gzipped example files (there should be no related lintian warnings).
* predictnls - made 1 test,
* profbval - made 1 test,
* pdb2pqr - added 3 tests, fixed lintian warnings. This package contains a big pipeline, in some cases it uses different subprograms, and some files were not installed when necessary - I fixed this. That's the reason why there are 3 separate tests. I couldn't utilize upstream tests/, because pdb2pqr uses complex built system (known as `scons`), and I haven't figured out how to do it yet. I plan to add them only to autopkgtest, because my tests check the same functionality as upstream tests, but they are simplier. Some upstream examples contains broken paths, I won't copy to examples them either. Except that these tests are is ok.
* proftmb - 1 test.
There are two serious reasons why I decided to slightly change my plan and for now to add tests for most part (or as much as possible) of RostLab's packages (and to shift in my timeline pymol/jmol, garlic and r-cran-bio3d and to work on them after finishing these packages):
1. I planned to work on predictprotein package, but realized that it's a big pipeline, and it uses several other RostLab packages, and some of them depend on others. When I made simple test, it shown the same deprecation error as described here:
http://www.perlmonks.org/?node=1077762In my case, deprecation error came from the predictprotein's dependency - librg-utils-perl. I noticed this closed bug #789410, but it seems that package still doesn't work well with perl 5.22 (I'll fix this problem after finishing this letter).
(There is another problem with default database paths, but I'll fix it after finishing tests to packages predictprotein relies on).
2. When I worked on profbval, there was a related package from the RostLab named 'profphd'. After problems with predictprotein tests, I became curious, and it turned out that it uses old version of perl (<=5.16). I installed it with perlbrew, but it still didn't work well (I'll provide some details if necessary in next letter).
I have seen that some of these packages has bugs - I'll try to fix them one by one after I'll do tests for corresponding packages.
____________________
Questions:
1. To check how `librg-utils-perl` works, I used Debian Perl Group's default perl packaging testsuite (
http://pkg-perl.alioth.debian.org/autopkgtest.html).
Is it fine if I use their recipe for perl libraries' testsuites - to add "Testsuite: autopkgtest-pkg-perl" to debian/control and use it instead of hand-written tests? At least in simple cases. For 'librg-utils-perl' I'll use this test for now.
(In fact I haven't used Perl before and for now I think that Debian Perl Group's testsuite will find more problems, than mine).
2. What is the proper way to add tests for profphd? I should run it with perl <=5.16, or to make it work in current unstable versions of perl?
3. There is also a stupid question about a package named 'pp-popularity-contest'. It knocks to rostlab server and sends simplest possible usage report. In fact, testsuite for this package can contain only 1 'control' file with 1 test command, with 'isolation-container' restriction.
This package also starts cron task, but I'm not sure how to check that task correct in proper way.
Debian Med Group Policy states that 'Packages of priority “extra” are excluded from some QA tests.', and this package has priority 'extra' - maybe I should skip it, or add just simple test with test command, or should I also check related cron job - what strategy would you suggest (and how to check cron job correctness properly)?