On Fri, 2010-07-23 at 10:17 +1000, Mark Goodwin wrote:
> I'll give this a whirl .. way too much sar data floating around
> where I lurk, so this will be a godsend :)
Let me know how it goes, I only have very limited sample data files to
work with. Needless to say there is no support here for Irix, Unicos,
Mac OS X, ... as their versions of sar are different (in sadc output
file format) and do not include sadf or equivalent.
> For packaging, I'd suggest we do this :
>
> libpcp_import.so goes into pcp-libs
I'm not sure how the rpm packaging works, but for debian we currently
(excluding sar2pcp) have these packages:
libpcp-import1_3.3.2_i386.deb
libpcp-import1-dev_3.3.2_i386.deb
libpcp-import-perl_3.3.2_i386.deb
> man/man3/*.3 and import.h go into pcp-libs-devel
> (and maybe rename import.h to pmimport.h ??)
Choosing import.h was deliberate.
We used to have a pmimport.h and I wanted to avoid any confusion. The
header hides inside /usr/include/pcp, so source references are
#include <pcp/import.h>
so the generic "import" is given a pcp context. And finally, the
library that matches the header is libpcp_import.
As to the packaging of the import tools, I've read the later mail
exchange between Mark and Nathan and suggest we have just one package,
possibly pcp-import, that includes _all_ of the import tools, a pmimport
wrapper if that is needed (unsure of this as yet), and dependencies for
_all_ of the tools ... some will be Perl modules from CPAN, some may be
binary modules like sysstat ... remember some of the tools will be in
Perl, but some might be in C.
This avoids polluting other PCP packages with unusual dependencies, at
the cost of getting all the prereqs satisfied if you want to install the
pcp-import package. And it prevents packages multiplying like rabbits.
|