Nathan, thanks for picking up the baton here.
There is a multiple sense of deja vu here. Like company reorgs,
changing the pcp packaging is one of those things that happens in a
cyclic fashion and the fact that it moves from one model to another and
back again suggests only one thing to me in my declining years ... there
is no nirvana here, and the packaging is going to be "unnatural" for
someone, always.
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.
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.
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.
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.
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.
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.
On Tue, 2009-02-03 at 13:10 +1100, Nathan Scott wrote:
> Hi all,
>
> Toward the end of last year, the good folk at SGI asked whether
> we could make kmchart more a part of PCP. In particular, there
> was discussion of whether there should be one source tree, and
> using the same naming convention as the other PCP tools.
>
> With the pending release of additional (SGI) monitoring tools,
> it would be good to have these issues sorted out, so there is
> clarity on where that code should end up in the oss releases.
>
> I'd like to solicit input before I go ahead and make any changes
> in this area. I only want to have to do this once, never again!
> If you have any thoughts or strong preferences on the direction
> taken (particularly with the planned actions outlined below),
> please let me know sooner rather than later.
>
> These are my thoughts/opinions/preferences:
> - I don't want to attempt to merge the two git trees, too much
> valuable revision history now exists, and the configure.in that
> is needed for each is very different (different tool chain)
> - I don't want a single install package (eg. named "pcp") as
> the "kmchart" package has lots of additional (GUI) dependencies.
> - Renaming kmchart/kmtime -> pmchart/pmtime is fine with me. I
> will keep symlinks for backward compatibility, etc.
> - Need a new name for the "kmchart" package. Suggestions have
> included: pcpgui, pcpvis, pcpviz, pcpmon, pcp-monitor. At the
> moment I'm favouring the last two, probably the last one as it
> is the most clear.
>
> These are my planned actions:
> - rename the kmchart git tree to pcp-monitor
> - rename the current pcp git tree to pcp-collector (removing any
> ambiguity, and making the packages consistent with some of the
> existing documentation)
> - split the current pcp rpm package into libraries, development
> packages and one pcp-collector package (pcp-3.0 timeframe, this
> has been requested by someone wishing to package us in Fedora).
> - rationalise libqmc and libpmc into one library as part of this
> transition (one library in the pcp-monitor package, not pcp),
> and rename kmdumptext to pmdumptext in the process.
> - Remove references to C++ compiler in pcp-collector configure
> process - all C++ code should end up in pcp-monitor hereafter.
> - rename libkmtime to libpmtime (this is a static-only lib atm,
> thankfully, but we should switch to making that shared as well).
> - update man pages, web pages, code, etc that refers to the km*
> names and instead use pm* names.
> - move pcpqa tree contents (back) into "qa" subdirectory in the
> pcp-collector git tree, so its clear what that is for. kmchart
> (aka pcp-monitor) already has a "qa" subdirectory.
>
> These things are likely to be done piece-by-piece and will take
> time. I'm also trying to focus on the native Windows PCP port
> at the moment (so, even more time), but would like to use the
> right names for km{chart,time,etc} in the first version of that.
>
> OK, any thoughts? Suggestions? Alternatives? Personally, I
> think these are very positive changes, especially for new users
> by removing the wierd historical naming oddities that have crept
> into how we package things.
>
> cheers.
>
> --
> Nathan
>
> _______________________________________________
> pcp mailing list
> pcp@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/pcp
|