pcp
[Top] [All Lists]

Re: [pcp] pcp updates - libpcp_import & PCP::LogImport

To: kenj@xxxxxxxxxxxxxxxx
Subject: Re: [pcp] pcp updates - libpcp_import & PCP::LogImport
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 26 Jul 2010 12:34:19 +1000 (EST)
Cc: pcp@xxxxxxxxxxx, Mark Goodwin <goodwinos@xxxxxxxxx>
In-reply-to: <1279880509.10802.16.camel@xxxxxxxxxxxxxxxx>
----- "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).  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.

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.

cheers.

-- 
Nathan

<Prev in Thread] Current Thread [Next in Thread>