Looking pretty good now - we're getting close :) More comments below ..
On 05/06/2015 05:38 AM, Lukas Berk wrote:
[..]
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.
OK, so now pmiostat has been pcp-foo'erized but there is no pmiostat
symlink. Also the man page has disappeared after the upgrade (see below).
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?
yes that was the intent of the pcp-foo mechanism but my question above
still stands - what are people's thoughts on this? I personally don't
really like it, which is why I originally shipped pmiostat rather
than pcp-iostat (and also because pmiostat isn't an exact drop in
replacement for iostat .. the latter has too many warts and the args
can never match up aynway) - I'm a complete and utter anti-sysstat
bigot!
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?
yep, it's no big deal anyway really
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.
OK, sorry I didn't see that first time. The pcp-compat spec rules look good.
I set up a local yum repo and tested an upgrade from pcp-3.10.3-1 on f21
with a simple "yum update pcp" and it pulled in pcp-compat and all the deps
followed from there. There are a couple of packages missing from the pcp-compat
dep rules though because the following pcp-3.10.3-1 packages were still
installed after the upgrade :
$ rpm -qa | grep 'pcp.*3.10.3'
pcp-webjs-3.10.3-1.fc21.noarch
pcp-import-sheet2pcp-3.10.3-1.x86_64
pcp-doc-3.10.3-1.fc21.noarch
pcp-debuginfo-3.10.3-1.fc21.x86_64
As a result there were a lot of missing man pages and debuginfo mismatched,
etc. I'll send a patch later today if I get time to fix this. Attached
below is a transcript of the upgrade.
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.
yep that's looking better now, with the above points to note. thanks.
Attached is the upgrade log.
Cheers
pcp-upgrade.txt
Description: Text document
|