Re: Automatic ITP checks (Was Re: Pending Packages List, 2003-11-26)

[Harold L Hunt II <huntharo at msu dot edu>]

Igor Pechtchanski wrote:
> Thank you for your work on the verification of the ITPs.

No problem.  I was bored.

> I'm sure we all
> appreciate the effort, and you're welcome to keep doing this if you're
> having fun at it, but it occurred to me that some of the steps in your
> verification could have been done automatically (to wit, run the build
> script, see if it produces the source and binary tarballs, check that the
> .exe files in the binary tarball are stripped, that the /etc/postinstall
> directory is nonempty if it exists, that the documentation is in
> /usr/share/doc, that there's a Cygwin-specific readme, that the package
> builds outside of the source directory, etc).  As time permits, I'll try
> to whip up a script that will do some of these for at least method 2
> packages (i.e., those using build scripts).

Are you talking about a script that is run manually by the package 
reviewer?  That would be a help.  Here are a couple of things an a 
"reviewer" script could automate for me:

1) The sample build script "all" command runs the finish command at the 
end, so you can't make local changes to the source files and use "all" 
to test them... since your changes will be lost if "finish" gets run. 
Instead you have to manually delete the .build and .inst directories, 
then run "mkdirs", "conf", "build", "install", "strip", "pkg", and 
"spkg".  I guess this could be easily fixed by adding an "almost-all" 
command to the default build script, but I haven't done it yet.  So, the 
reviewer script should leave everything in place after it is done so 
that changes can be made and things can be tried again.

2) Check that the patch file is non-zero in size.  That detects all 
sorts of problems, like installing the CYGWIN-PATCHES files in a 
non-standard manner or not providing any CYGWIN-PATCHES files.

3) Do something similar to a "make distcheck" to check that the "spkg" 
command produces a file with identical contents to the file it is built 
from.  This is useful for catching weird errors like the version number 
being continually appended to the build script filename.

4) Pie in the sky: Run cygcheck on *.dll and *.exe, make a unique list 
of dependencies (.dll files), check the package info for which packages 
provide this .dll files, and, at a minimum, print out a list of packages 
that this package is dependent upon.  I think you could get such a list 
with either a recursive check of deps or with a depth one check and 
making sure that cygwin1.dll is listed as a dep at one level in.  You 
get the point...  Right now I do this manually and check that anything 
that looks like a Cygwin-provided DLL is listed in the "requires: " 
section of setup.hint.

> The ITPs
> will still benefit from human eyeballing, but at least the tedious part of
> the work will be standardized...

Yes, I did a little more than just check that most of these packages 
were well-formed :)

> BTW, if the checks are quick enough, there's no reason why they can't
> be done on the package updates as well, before they're uploaded.  This
> way, no errors will creep in on package updates.

Might be a good idea if the script is perfected.

Harold