This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]