Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: gkrellm - Multiple stacked system monitors in one process
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197967
------- Additional Comments From j.w.r.degoede@hhs.nl 2006-07-14 14:57 EST ------- (In reply to comment #1)
I'm a firm believer in that users/groups created by packages should *not* be erased when the package is removed, and won't set myself as the reviewer because of that. Let me know if you're willing to leave them behind when erasing -daemon, and I'll take care of the review.
Sure, that sounds reasonable, how does one pick up the leftover user when the user decides to reinstall the package later?
Anyway, a couple of comments:
The switch to lm_sensors means that ppc will need special treatment, as lm_sensors is not (nor obviously -devel) available for it. ExcludeArch: ppc would sound like a regression.
That patch was written in communicatiopn with upstream and is going to appear in the next upstream release. All the changes are wrapped in #ifdef HAVE_LIBSENSORS, hence the adding of -DHAVE_LIBSENSORS to CFLAGS. I'll make the adding off that conditionally with %ifarch, does that sound ok?
-daemon has grown a "Provides: gkrellm-server" for no apparent reason, and -daemon has become self-obsoleting because of that, which may or may not cause problems. I'd suggest removing it and adding a "< $some_known_version-$release" to Obsoletes: gkrellm-server.
Erm rpmlint complains without it. I'll remove the Provides. Are you sure this makes a package self obsoleting?
There's a mismatch between %install and %files where the former uses various hardcoded paths while the latter uses macros (at least /etc vs %{_sysconfdir}).
I'll do a new version with %{_sysconfdir} everywhere + other fixes once I've got a reply to my above remarks / questions.