Some pcp clients are happy to use PM_CONTEXT_LOCAL with a small handful of C .so PMDA's (linux_proc e.g.), but are unhappy that these pmdas are only packaged in the central 'pcp' rpm, which has perl/python/etc. prerequisites. We should break up the 'pcp' rpm so that the footprint for small clients is small. - the default pmns/root is either not used at all, or is provided in generated capacity by the build, instead of being generated during first -pmcd- startup - pmdas that need perl are separated out into at least one subrpm; likewise python - plain C (no-further-big-prereqs) pmdas are separated out into at least one subrpm (without depending on base pcp) - if needed, libpcp adjusted PM_CONTEXT_LOCAL can use the pmda subrpms without needing other pcp binaries / nontrivial config files - probably: invent a mechanism where libpcp can find .so pmdas by searching the pmda directories rather than scraping pmcd.conf, e.g., a __pmSpecLocalPMDA keyword "scan", searching $PMDADIR and stdpmid.pcp / stdpmid.local? (This should also shrink the hurdles for a default-on local-pmlogger installation.)
*** Bug 1184403 has been marked as a duplicate of this bug. ***
Other places where improvements should be made: - remove the direct dependency in libpcp on the Avahi libraries - all discovery/advertising methods should become runtime configurable and extensible outside of PCP. - remove the direct dependency in libpcp on NSS/SSL, Dave has completed almost all of the work for this now - someone just needs to go the last dlopen step. - pmwebd seems to have acquired a dependency chain that includes some 10-15 X11/desktop/font libraries, and associated rpm dependencies, as a result of using the Cairo library. Its resident memory footprint has doubled as a result, combined with the switch to using C++ - would be worth considering a more dynamic plugin model for pmwebd, as people will want to use it on servers without all those X11 rpms. The "invent a mechanism" line in original report wont fly as described I suspect - IIRC pmcd.conf was used because these PMDAs are known to have root namespace entries, which is required in local context mode also - so a design which considers the metric namespace would be needed.
Apprx. all those libraries are already split into separate -libs type subrpms, so beyond their genuinely useful function do not constitute unnecessary or peculiar overheads. One should need a pretty well-justified case to justify reinventing ordinary dynamic linking.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
pcp-3.10.5-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/pcp-3.10.5-1.fc22
pcp-3.10.5-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/pcp-3.10.5-1.fc21
pcp-3.10.5-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/pcp-3.10.5-1.fc20
pcp-3.10.5-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/pcp-3.10.5-1.el5
Package pcp-3.10.5-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing pcp-3.10.5-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-6718/pcp-3.10.5-1.el5 then log in and leave karma (feedback).
pcp-3.10.6-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/pcp-3.10.6-1.fc22
pcp-3.10.6-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/pcp-3.10.6-1.fc21
pcp-3.10.6-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/pcp-3.10.6-1.el5
Not a huge deal, but this bug shouldn't be considered fixed when associated with OS versions where the pcp -> pcp-compat -> pcp-mostly-everything dependency chain is active.
pcp-3.10.6-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.6-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.6-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.