Here's some more packaging review after building Lukas' tree on an f21 box.
0. Overall, I like the new packaging, especially that all the PMDAs have been
split out - we isolate dependencies and minimize install sizes - all good.
1. if rpm-devel isn't installed, the build fails :
== Building rpm packages, log is in /home/mgoodwin/src/pcp-lberk/Logs/pcp
Packaging RPMs via pack_pcp failed, see log in
/home/mgoodwin/src/pcp-lberk/Logs/pcp
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man3/pmiInDom.3.gz
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man3/pmiUnits.3.gz
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man3/pmiunits.3.gz
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man1/pmie_daily.1.gz
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man1/pmlogger_daily.1.gz
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man1/pmlogger_merge.1.gz
Explicit %attr() mode not applicaple to symlink:
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/BUILDROOT/pcp-3.10.5-1.x86_64/usr/share/man/man1/pmsleep.1.gz
Could not open %files file
/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/pcp-3.10.5/pmda_rpm_files.rpm: No such
file or directory
make: *** [pack_pcp] Error 1
make: Leaving directory `/home/mgoodwin/src/pcp-lberk/pcp-3.10.5/build/rpm'
After installing rpm-devel, the build completed successfully.
Looking in the configury, /usr/include/rpm/header.h wasn't installed so
the rpm PMDA doesn't get built, so no pcp-pmda-rpm package will be built.
I guess we need conditionals in pcp.spec.in to handle this sort of thing.
Other PMDAs are probably affected too if their specific build deps (or
devel package whatever) aren't present.
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!)
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, ..?
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)
existing packaging (latest master branch) :
$ rpm -qlp *.rpm | wc -l
6001
new packaging:
$ rpm -qlp *.rpm | wc -l
5970
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?
Regards
|