Hi, This is totally off-topic (it''s an rpm/rpmbuild problem), but I want to get to a point where I''m installing and configuring munin-node with puppet. To do that, I need a clean, standardized way of installing munin-mode on CentOS (RHELish) boxes. I could install munin-node from source via puppet and probably make enough edits that all the files end up in reasonable locations (a problem with installing from source vs from RPM.) It would work but it''s fairly unclean in a managed environment, and I''d rather not follow that path. I could rebuild munin-node RPMs or use them from a third-party repository. I''ve fixed the major problems with the spec file shipped with the munin 1.2.5 source to the point that I can rebuild the RPMs; alternatively, I can rebuild the Dag Wiers SRPM for munin to get munin-node RPMs. Either way, these RPMs suffer from a flaw - they can''t find their prerequisites even though they''re installed and available when the code is installed from source (via CPAN.) The major problem is Net::Server::Fork which is included in the Net::Server distribution. As a rule I install the fewest perl modules as possible as RPMs because perl has a perfectly good package management system which is updated faster and better than any vendor''s RPM repository. My experience is that perl module RPMs just cause problems so I avoid them. Unfortunately, I believe the munin-node RPMs expect certain perl dependencies to also have been installed as RPMs and I can''t convince rpm to either find the dependencies in the perl module tree or not look for them at all. Despite stripping dependencies out of the spec file, rpmbuild ''helpfully'' adds them back in by parsing the source code. My options are to use --force or --nodeps or to build dummy packages to fake out rpm. None of those are reasonable options[1] so I''m back to installing from source because the existing package management is quite simply b0rk3d. Is there a clean solution to this problem? At this point, installing from source seems cleanest but I was hoping someone with a better grasp of RPM knew of a better way to solve this. -- Bob [1] I don''t want to get in the habit of overriding or lying to my package management system and I don''t want to leave this as my legacy when someone else takes over this system. The munin-node RPM should be installed cleanly and independently or not at all.
Bob Apthorpe wrote:> As a rule I install the fewest perl modules as possible as RPMs because > perl has a perfectly good package management system which is updated > faster and better than any vendor''s RPM repository. My experience is > that perl module RPMs just cause problems so I avoid them. > > ... > > Is there a clean solution to this problem? At this point, installing > from source seems cleanest but I was hoping someone with a better grasp > of RPM knew of a better way to solve this. > >Have you considered using cpan2rpm for maintaining your Perl modules as RPMs? It can be a bit touchy, but overall works very well. Mark -- Mark D. Nagel, CCIE #3177 <mnagel@willingminds.com> Principal Consultant, Willing Minds LLC (http://www.willingminds.com) cell: 949-279-5817, desk: 714-630-4772, fax: 949-623-9854
On 5/25/07, Bob Apthorpe <apthorpe@cynistar.net> wrote:> This is totally off-topic (it''s an rpm/rpmbuild problem), but I want to > get to a point where I''m installing and configuring munin-node with > puppet. To do that, I need a clean, standardized way of installing > munin-mode on CentOS (RHELish) boxes. > > I could install munin-node from source via puppet and probably make > enough edits that all the files end up in reasonable locations (a > problem with installing from source vs from RPM.) It would work but it''s > fairly unclean in a managed environment, and I''d rather not follow that > path. > > I could rebuild munin-node RPMs or use them from a third-party > repository. I''ve fixed the major problems with the spec file shipped > with the munin 1.2.5 source to the point that I can rebuild the RPMs; > alternatively, I can rebuild the Dag Wiers SRPM for munin to get > munin-node RPMs. > > Either way, these RPMs suffer from a flaw - they can''t find their > prerequisites even though they''re installed and available when the code > is installed from source (via CPAN.) The major problem is > Net::Server::Fork which is included in the Net::Server distribution. > > As a rule I install the fewest perl modules as possible as RPMs because > perl has a perfectly good package management system which is updated > faster and better than any vendor''s RPM repository. My experience is > that perl module RPMs just cause problems so I avoid them. > > Unfortunately, I believe the munin-node RPMs expect certain perl > dependencies to also have been installed as RPMs and I can''t convince > rpm to either find the dependencies in the perl module tree or not look > for them at all. Despite stripping dependencies out of the spec file, > rpmbuild ''helpfully'' adds them back in by parsing the source code. > > My options are to use --force or --nodeps or to build dummy packages to > fake out rpm. None of those are reasonable options[1] so I''m back to > installing from source because the existing package management is quite > simply b0rk3d. > > Is there a clean solution to this problem? At this point, installing > from source seems cleanest but I was hoping someone with a better grasp > of RPM knew of a better way to solve this. >You can filter out the perl module requirements from your munin-mode package. Unfortunately, this means you end up with a munin-mode package that will be broken if it is installed without the CPAN modules by someone else. This isn''t much different than doing "--nodeps" although that ignores all dependencies instead of just the Perl module ones. There isn''t any way to tell RPM that some dependencies have been installed outside of packages. Building packages for Perl modules isn''t too hard. I prefer to build packages for modules and install everything through yum. RPM is a much better package manager than CPAN. I find that the cpanspec tool works well for building modules. Also, the EPEL project is bringing packages from Fedora Extras to Centos/RHEL. I think perl-Net-Server is one of them. - Ian