Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=749232 --- Comment #7 from Ricardo Rocha <rocha.porto@xxxxxxxxx> 2011-11-17 14:13:19 EST --- Hi. See explanations below before i provide a new package (if one is needed). > [=] MUST: A package must own all directories that it creates. If it does not > create a directory that it uses, then it should require a package which does > create that directory. > /etc/nagios.d is now owned or required but see below. > > Also you should probably own. > > /usr/share/pnp4nagios > /usr/share/pnp4nagios/lcgdm-templates I'll double check this one. It looks line pnp4nagios provides /usr/share/nagios/html/pnp4nagios, so maybe it's more logical to add a lcgdm directory there. > Comments: > 1) The layout of files between packages does not make sense to me. > e.g. > nagios-plugins-lcgdm-0.4.0-3.fc16.x86_64.rpm > contains > /usr/share/pnp4nagios/lcgdm-templates/check_dpm_perf.php > and all the php4nagios files > but > nagios-plugins-dpm-head-0.4.0-3.fc16.x86_64.rpm > contains > /usr/lib64/nagios/plugins/lcgdm/check_dpm_perf > > there should be some correlation between files for the same probe > or alternativley probes in one and php4nagios files in another > though the first is a better option. I didn't put them with the probe, as the probe is to be run on the monitored host, while the template is needed in the monitoring host (where the web interface is running). Unless we also install all the probes in the Nagios host, but they're really not needed as they're run remotely with nrpe. The current layout is pretty much one rpm per 'node type' - dpm-head, dpm-disk, lfc and lcgdm (lcgdm meaning the nagios master itself, nagios-plugins-lcgdm-nagios being a weird name). The second option you suggest is splitting the templates into additional packages following the probe layout? Something like: nagios-templates-dpm-head|dpm-disk|lfc? I couldn't find any existing packages with names suggesting this. > 2) You have > %define debug_package %{nil} > this must be justified with a comment or removed. If i remove it i get from rpmlint: ... nagios-plugins-lcgdm-debuginfo.x86_64: E: empty-debuginfo-package and as it was an error i added it. There's nothing in the packages generating debuginfo, i guess that's why it's empty (they're all python probes). > 3) I don't understand the /etc/nagios.d directory at least on > Centos6 where I am looking nagios does not contain this directory, > is this something you are introducing? I presume these > are probe configuration files. I guess it is. Nagios gives the option of a confdir (or several), and /etc/nagios.d seemed logical, although it does not seem to be standard. Should we call it something else or simply own it like this? Maybe /etc/nagios.lcgdm.d instead just to make sure we don't clash? > 4) arch vs noarch, I appreciate the problem that the path is > architecture dependent when it comes to nagios locations > reguardless of the file contents. > If after reording the files between packages you end > up with out a non-architecture path then that sub package > can be marked noarch except for on .el5. > > Someone really should tackle this in a future nagios version but > not your problem for now. All the packages have probes, so i guess for now they can't be noarch? > 5) Adding nagios-common and nagios-plugins is probably > fine. I think neither of these actually require nagios which is > worth leaving behind. Yes, confirmed. > 6) As long as LICENSE is pulled in by every package that can > be installed in isolation to the others you are fine, more > over you should not supply it elsewhere. Only provided in lcgdm-common, guess it is ok? I'll provide a new version right after these issues are cleared up. Thanks! -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review