[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