[csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity

[Maciej (Matchek) Blizinski]

If you don't use GAR, you can stop reading now.

The v2-checkpkg branch has been merged to v2 today.  It means that the
new shared library checking code is now live.  The next time you
update your GAR sources, the new code will be pulled in.

The new code doesn't affect the way the packages are made, it only
affects the way the new packages are being checked.  There are two
main differences:


1. There is new library checking code.  It's emulating the way the
shared libraries are searched on the filesystem.  The first time you
run it on each machine, it builds a cache of
/var/sadm/install/contents, so please be patient and give it up to two
minutes to complete.  Subsequent runs will be fast, and in fact,
faster than the previous code, because it doesn't read the contents
file each time.

One of the main differences in output is that the new check displays
dependencies it thinks are unnecessary.  I found it a useful feature.
For instance, I found out that syslog-ng was reported to have an
unnecessary dependency on CSWtcpwrap.  Upon close examination, it
turned out that syslog-ng was supposed to have tcp wrapper support,
but it was just not compiled in.  If checkpkg hasn't tipped me off, I
wouldn't have known or fixed this issue.  I'm sure other people will
be able to catch some problems by looking at this part of checkpkg's
output.

The new code outputs also information about dependencies between
binary files: which files uses which shared library, and which package
provides the library in question.

I suspect that the new code might be slightly more picky and may
produce more false positives than the previous one.  If you run into a
false-positive, or any kind of problem with library-related checks,
please drop me a line.  I've got small debugging infrastructure
integrated into the new checkpkg files.


2. Modular checks have been introduced.  The gar/bin/checkpkg.d
directory contains now separate checks.  The checks are executable
files, which can be written in any language.  Communication is over
command line flags and system exit codes.  Output from each check is
collected and displayed at the end of the run of checkpkg.  It won't
stop on the first failure; all errors will be collected and displayed
at the end.  The intention of the modular checks is that people can
introduce their own checks without having the problem of unexpected
interactions with other checks or global variables.  This should make
it easier to collaborate: each person can program in their own
favorite language, and it's easy to develop new tests.

Each test evaluates a set of packages, not just an individual package.
 It makes checks slightly more complex, because they have to loop over
the list of packages to check.  However, the set tests are necessary
anyway, and I think it's a better approach to have only one type of
test rather than two.  If people think that individual tests are also
useful, let's discuss it.

I haven't integrated any of Ben's code yet, but I've looked at it and
borrowed some ideas.  I would like to start incorporating his
cswpkgtest code.  I think that some tweaks to lib/pkg_testfuncs.sh
should make his existing tests compatible with checkpkg.d.

If you have any questions, I'll be happy to answer them.

Maciej