On Wed, 2009-02-04 at 07:27 +1100, Ken McDonell wrote:
> ...
>
> Getting the GUI-based components out on their own seems like a good
> idea, with no real downside.
>
> But it immediately gets tricky after that. Consider
> - pmprobe
> - pminfo
> - pmval
> - pmdumptext
>
> These are all "monitoring" tools, some are required for pmda installs,
> some should just always be there (pminfo and pmprobe), one of them has a
> weak dependency on the GUI time control component (pmval) and one of
> them depends on C++ (pmdumptext).
>
> It gets even messier with pmie and the unconditional dependence
> pmdasummary has on pmie.
>
> Then there is pmlogger and all of the logger control stuff.
>
> Personally I think it would be better to more or less keep the current
> open source package with its current contents and keep calling it pcp,
> and move any GUI components to pcp-gui (or some such, rather than
> pcp-monitor as there will be other non-gui "monitoring" stuff in pcp).
>
> This keeps the git trees.
>
> This isolates the GUI-dependent build and install into a separate
> package.
General *nod* to all of the above. My main sticking point is
pmdumptext. I want to have kmdumptext become pmdumptext, and
have all C++ code in one place using the one library instead of
dup'ing this. This was what pushed me to the pcp-monitor name,
instead of pcp-gui. At some point kmdumptext will get a kmtime
interface, which will likely be a QMC class shared with kmchart,
which will mean pmdumptext is stranded back over in the base
"pcp" package (cos the build dependency goes the other way).
So, I'm thinking the kmdumptext -> pmdumptext transition must
still happen, and we'll just live with the oddity that pmdumptext
lives in "pcp-gui" ... that sound reasonable?
> This leaves _most_ installations (the systems being logged and
> monitored, there are thousands of these) with a single package to be
> installed to provide all the functionality they need and very little in
> the way of excess baggage. The smaller number of installations are
> monitoring desktops with a simple 2 package installation and dependency.
>
> I'm not sure pcp-dev would add value, it probably only contains a
> handful of headers, and since we build some bits from source in pcp,
> they already need to be in pcp anyway.
>From the Linux distributions point of view, they now insist on
a package break out of:
- shared library runtime,
- development headers and static library
- layered/main package(s)
This needs to be done for rpm at some point (Fedora people have
already requested this), it was done for deb from the start. As
builds are often done chroot'd, having a full pcp rpm install,
with /etc/init.d/pcp start exitops, etc, is problematic (takes
out pmcd on the build machine, during a chroot build) ... which
has bitten SGI in the past. But, this is a rpm-specific issue,
doesn't affect the source tree layout... we can come back to it
later.
> There also appears to be ample precedent for the bozo and bozo-gui
> naming scheme in existing packages.
>
> Renaming kmchart -> pmchart and kmtime -> pmtime is fine if the sgi
> proprietary pieces are cremated.
OK, everyone seems on board with this part of the plan.
> Rationalizing libpmc and libqmc is probably sensible if someone is brave
> enough ... just beware that history in this area suggests the mother of
> all metrics classes probably does not exist.
I'm brave enough to nuke pmdumptext from the pcp tree and
rename kmdumptext ... not brave enough to take on metrics
class extensions beyond that at the moment (but a kmtime
class is on the cards).
> We also should consider the overhead of managing the repositories when
> (rather than if, I suspect) we decide to move them off oss.sgi.com ...
> less packages would be better at that point.
Its possible this day will come, but for now oss.sgi.com is a
good place to get work done. As a backup we do have options,
but lets have that discussion if/when the need arises.
> I strongly believe pcpqa should remain outside the main tree(s) ...
> since there are so few people who would use this, no matter what it is
> called, the name is sort of irrelevant imho.
OK. It means pcp-gui has its own embedded qa, whereas pcpqa is
separate to pcp ... but doesn't really matter. We could take
qa for pcp-gui out of that tree and move it into pcpqa? *shrug*
... not a high priority.
So, to sum up my current thinking:
- basically same source tree structures, kmchart becomes pcp-gui
- km* -> pm* executables rename goes ahead
- we'll have pcp-gui not pcp-monitor (Mark wanted that too, so
I'm outvoted on this one, and theres no right answer really)
- the pcp rpm packaging rework I think still needs to happen,
but that will come later & hopefully someone else can do this
(hopefully entirely within pcp.spec.in too...)
- pmdumptext-in-pcp replaced by renamed-kmdumptext-in-pcp-gui
- old PMC code dropped in favour of its derivative, QMC.
cheers.
--
Nathan
|