[topic changed to checkpkg plugins] 2011/3/7 Ben Walton <[email protected]>: > What about 'plugins' to checkpkg. These would still be scripts (any > language) but would be run by checkpkg. They could be triggered by > an environment variable or some other mechanism that points checkpkg > at a directory to use. > > The checkpkg run could then call each script in the directory and bail > if $? != 0.
The environment in which the checking functions run, is somewhat restricted. - no access to original .pkg file - no access to unpacked files - no assumptions about the host architecture, OS release, or even the operating system type can be made The checking code can only communicate with a designated interface, which allows to make certain queries or assertions, e.g. "which packages contain files named libbar.so.1, an in which directories are these files?", or "Package CSWfoo needs file /opt/csw/lib/libbar.so.1 because binary /opt/csw/bin/foo has libbar.so.1 in NEEDED and /opt/csw/lib in RPATH". The data available to the checking functions are in the form of a single data structure, a combination of dictionaries and lists. It is possible to fit a plugin architecture into the existing code, if communication paths are provided. I could imagine a bit of Python code which would wrap plugins from a certain directory, and took the responsibility of communicating with them. Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
