Hey Mark,
First off, thanks for taking a look, comments inline.
Mark Goodwin <mgoodwin@xxxxxxxxxx> writes:
[...]
> 1. if rpm-devel isn't installed, the build fails :
I've applied your patch upstream (maintaining your authorship) on
lberk/dev, thanks.
[...]
> 2. the pcp-systemtools package contains the pcp-foo front-ends - what are
> everyones thoughts on the two approaches: pcp-foo, or pmfoo. Just keep
> shipping both styles? Or be more consistent and choose one or the other?
> Also, there might be some confusion over pcp-systemtools verses pcp-monitor?
> (newbie user might not realize pcp-monitor is a meta package and thus
> wonder why the systemtools aren't in the monitor package, and indeed
> why the pcp-monitor and pcp-collector packages are actually empty!)
FWIW, with the changes to pcp.spec.in, I've used symlinks to maintain
the original invocation of the tool, whatever it may be. The changes
simply reflect pulling the tools into their own package. AIUI, the
pcp-foo functionality was meant for tools (aka, pcp free) to match the
native tool's invocation, do we want to change that?
As for the pcp-system-tools vs pcp-monitor distiction, would added
pieces in the description of each rpm ease your concern regarding what a
newbie user might be expecting?
> 3. upgrading a minimal existing pcp installation (e.g. pcp, pcp-libs but
> not much more) will end up with a lot of stuff missing after the upgrade
> because the new pcp package has much less in it, e.g. the files in the
> new pcp-systemtools package, a bunch of PMDAs have been split out, etc.
> I guess we can't avoid this, it's a consequence of the new minimal
> packaging regime, ..?
That's part of why I've rquired the pcp-compat package on fedora
installations fed22 or older as well as rhel7 and older, basically, any
currently supported platform shouldn't change. In the event somebody
upgrades (say fedup from f22 -> f23), it is the administrators
responsiblity to check for update issues, which is true above and beyond
PCP. If we can provide any more warning functionality to ease the
transition, I'm all for it. The line has to be drawn somewhere and I
think rawhide is an appropriate place to start.
> 4. some stuff seems to be missing - this is top-of-tree master compared
> to Lukas' tree (latest master has moved on a bit e.g. new qa files. But
> this needs to be checked)
Good catch. Judging the difference between the most recent master
commit in the lberk/dev branch however, was much closer (thankfully).
I've pushed a commit fixing this in lberk/dev now, and after inspecting
the diff (using the rpm -qlp *.rpm ... invocation), I think we're good
to move forward here.
[...]
> There are some new qa files and so forth in latest master, but I did notice
> pmiostat is not in any of the new packages (used to be in the pcp package).
> Didn't run a full diff. The old spec has a "catch-all" for anything that
> didn't end up in a specific package - these files were put in the pcp package;
> maybe that's no longer working?
It was actually changes in their respective GNUMakefiles that caused the
issues. Apparently my merge strategy of choice earlier sucked. Please
let me know if there are any other concerns, and if you'd like anything
else regarding the pcp-system-tools v pcp-monitor distinction.
Otherwise I'll get started on tweaking their descriptions to make it
more apparent.
Cheers,
Lukas
|