Hi All,
I was asked to take a look at minimizing the base PCP installation
(RHBZ1182184[1]) and was experimenting with a few aspects of it. I'd
like to get some feedback before I start more indepth hacking on it.
Providing a default pmns, and not requiring a Rebuild invocation when
the pmcd service initially starts:
I briefly experimented with this, by removing the initial .NeedRebuild
related commands in the GNUMakefiles and spec files, and running various
groups of the testsuite (sanity, verify, pmns, pmcd, pmda.linux,
pmda.pmcd, pmda.proc) with a fresh installation. There were no glaring
failures, related to not having a rebuilt pmns, afaict. In an effort to
better understand this area, what was the historical reason for
rebuilding the pmns upon the first pmcd start? In the case the
buildroot/platform was different that the target installation? If this
is a known issue on some select environments, perhaps we could still
keep/make use of the .NeedRebuild file for those platforms?
Splitting pmdas out into separate packages:
I think this makes more sense to do on a per-pmda level than a language
dependency basis, outside the core pmda's installed by default. I
recognize it may be a bit more work up-front on the packaging side of
things. However, it will (imho), be easier, and make more sense, for
the end user to be able to search for pcp-pmda-foo, and not being
required to know the implemenation the pmda was written in (aka, know to
search for pcp-pmda-python, not to be confused with the python pmda
bindings package). The only pmda (afaict) that has both perl and python
bindings is the Simple pmda. Considering this pmda only exports
synthetic metrics for developers, I'm ok with this package/rpm dragging
in both perl/python deps.
Another point to keep in mind with separate packages for each pmda, is
ensuring the upgrade path (assuming something along these lines makes it
into an upcoming release) accounts for the "new" split packages remained
installed. The fedora packaging guidelines[2] state the use of a
temporary pcp-compat style package for existing/stable fedora release,
which will require the new pmda level packages to be installed. We
could then make use of Rawhide to remove this pcp-compat package and
require users to individually install the pmdas. While this is starting
with Fedora, I've also briefly looked into Debian[3], though, I'd
appreciate input from folks more experienced than I on how debian deals
with splitting existing packages.
Splitting python client tools:
I think the best approach for pmtools written in python, is to split
them into a pcp-python-tools style package. I realize this is somewhat
contradictory to the approach for pmda's. However, given the relatively
smaller number of python tools, I think it makes more sense. We can
perhaps deal with the discoverability aspect (aka, making the mapping
of, say, pmatop with a pcp-python-tools package), by moving pmatop,
pmcollectl, pmiostat and pmgadgets tools, under the src/pcp script (similar
to numastat, free, etc). The pcp(1) script, could check for the python
dependencies and python-tools package, and if unavailable, advise the
user accordingly. We could also provide a symlink from previous the pmtool
bin name, to the 'pcp <tool>' invocation.
Removing direct dependency in libpcp on Avahi:
I took this to mean, add a ./configure --without-avahi option (invokable
via ./Makepkgs) which configures functionality via buildefs.h
accordingly in libpcp. Nathan, is this what you had in mind?
Pmwebd dependencies on X11/desktop libraries:
Considering pmwebd is already it's own package, which doesn't have to be
installed on the collection machines (rather, could be install on the
sysadmin/developer's machine). I'm not sure if this makes sense to
persue immediately. Can we even remove the dependencies given the very
graphical nature of the tools? I'm not able to discern the differnce
between the pmwebd package and pcp-gui package in this regard.
Removing the direct dependency in libpcp on NSS/SSL:
It sounds like this is already well thought out and doable. Any
objections to it being an action item?
Other thoughts:
Considering one of the underlying motivations of this item is to make
PCP more appealing to ship in a container environment, I think it's
important to point out man pages aren't shipped by default in many
containers. It could be worth looking into either, shipping them with
the pcp-doc sub pacakge, or splitting them into their own pcp-man-pages
sytle package. Otherwise the default installation will drag in man-db
style dependencies.
Any thoughts and comments are appreciated, otherwise, I'm going to start
with the pmdas, and move on from there.
Cheers,
Lukas
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1182184
[2] -
https://fedoraproject.org/wiki/Upgrade_paths_â_renaming_or_splitting_packages?rd=Upgrade_paths_#.28n:m.29_Many_to_many_replacement
[3] - https://wiki.debian.org/PkgSplit
|