On 07/26/2010 12:34 PM, Nathan Scott wrote:
----- "Ken McDonell"<kenj@xxxxxxxxxxxxxxxx> wrote:
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.
I think this would be OK - having a "core" import package for the
majority of things, with dependencies on not-too-outlandish things
(like Perl spreadsheet& XML modules).
ok, pcp-import it is. I'll pull in Ken's tree and do the packaging
work + version bumps in dev to make this happen, and ..
I still think we will end
up with the need for specialist import packages outside of this -
it just wont be workable for something to depend on, say, Oracle
and Sybase, and SQLServer libraries, for example - I think people
will rightly cry-foul at that.
.. ensure we have appropriate infrastructure for pcp-import-xyz
sub-packaging where needed to isolate exotic deps when they flare up.
The hybrid system we now have for PMDAs - where "core" PMDAs with
not-too-exotic dependencies live in core PCP, and things like
infiniband and cluster have moved out to their own packages, seems
like the right approach here too.
well yes, but in those cases they've moved into their own tree,
which is quite a bit more dramatic than just sub-packaging.
We need to avoid trees breeding like rabbits too - I'd really
rather that stuff came back into the pcp tree eventually.
Cheers
- Mark
ps: /me is currently bombarded with iostat data - I can see iostat2pcp
happening before too long :)
|