pcp
[Top] [All Lists]

Re: rpm dependencies

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: rpm dependencies
From: Max Matveev <makc@xxxxxxxxx>
Date: Sat, 9 Nov 2013 05:29:23 +1100
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1571433931.22843820.1383860474036.JavaMail.root@xxxxxxxxxx>
References: <21115.57413.974649.418399@xxxxxxxxxxxx> <1571433931.22843820.1383860474036.JavaMail.root@xxxxxxxxxx>
On Thu, 7 Nov 2013 16:41:14 -0500 (EST), Nathan Scott wrote:

 nathans> The idea is to allow development using pcp libraries, headers,
 nathans> and perly/snakey bits without having to install pcp itself (and
 nathans> hence have to worry about starting daemons and so on).

Ah, I've misunderstood the intent then - I was thinking that you were
trying to make life easier for the end user like it was done in the
past by unbundling Infiniband bits from the main package.

I was doing a "demo" of PCP and needed to install it on a VM which
doesn't have access to yum so getting all the prereqs was major pita.

On Thu, 07 Nov 2013 14:40:29 -0500, Frank Ch Eigler wrote:

 fche> It's a judgement call as to how finely to subdivide the pcp packages.
 fche> To partition the dependencies further, we'd need at least three new
 fche> subpackages:

 fche>         - pcp-pmwebd        (for the libmicrohttpd user)
 fche>         - pcp-python-tools  (for pmatop, pmcollectl, etc.)
 fche>         - pcp-perl-tools    (for the pmdas)

 fche> It could get unsightly.  Though at some point we might do this kind of
 fche> thing, say if in the future we want to segregate pure
 fche> agent/target-side stuff from clients.

>From my PoV the sooner the better - I really like the idea of having
"base" pcp with minimal prereqs and keeping "extras" for those who
need/want them.

max

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