[Bug 487114] Review Request: gvrpcd - A program for announcing VLANs using GVRP.
bugzilla at redhat.com
bugzilla at redhat.com
Thu Mar 5 12:51:40 UTC 2009
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=487114
--- Comment #6 from Michael Schwendt <bugs.michael at gmx.net> 2009-03-05 07:51:38 EDT ---
> gvrpcd.x86_64: W: service-default-enabled /etc/rc.d/init.d/gvrpcd
This is acceptable. Especially due to the new initscript, which exits early
when not finding a vlan config.
> gvrpcd.x86_64: W: incoherent-subsys /etc/rc.d/init.d/gvrpcd $prog
A false positive as explained by rpmlint -i. If you have strong feelings about
it, you can define
lockfile=/var/lock/subsys/gvrpcd
directly after the exec=/prog= definitions. I mean, it's not that you would
change this value often, so reusing $prog during definition of lockfile is not
much of a benefit.
About the defaults in the initscript, this is less than ideal. Currently, there
are _three_ places where configuration values are defined:
1) the daemon's built-in defaults (time=3, eth0, /proc/...)
2) your initscript defaults (time=3, eth0, /proc/...)
3) the sysconfig file (commented out)
Isn't that overhead? Wouldn't it be better to use the daemon's defaults and let
/etc/sysconfig/gvrpcd contain only
GVRPCD_OPTIONS=
or
GVRPCD_OPTIONS="-i eth0"
plus a comment on "gvrpcd -h" (or a future manual page)? In the initscript,
you would simply source /etc/sysconfig/gvrpcd and add $GVRPCD_OPTIONS to the
daemon's required -d arg. Much more simpler to rely on the daemon's defaults
(also explained in -h output), which may change. You would not have multiple
places that refer to different defaults.
> Usage: gvrpcd [-dvh] [-f configfile] [-d iface] [-i time]
This is wrong. Should be: ... [-i iface] [-t time]
--
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.
More information about the Fedora-package-review
mailing list