Hylafax review issues

[Jason L Tibbitts III]

One of the oldest review tickets still open is
https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
hylafax.  Earlier this month I picked this up an attempt to try and
shepherd it through the process, but I'm stuck on a couple of issues
and the submitter does not seem to be willing to address them
satisfactorily.  Maybe I should just say "hell no" and drop the
review, but I guess my objections could be wrong so I figured I'd try
to start some discussion.

Issue one is the name: There are multiple pieces of software claiming
to be hylafax.  There's the software at hylafax.org, and then there's
the package at hylafax.sourceforge.net, where it is called
"hylafax+".  I quote:
  The "+" means that it is better.

There's also an "enterprise" version from ifax.com.  The second
version, which upstream calls itself "hylafax+" is the one being
submitted, but the submitter argues against using that name (see
comment 38):
  However, my suggestion would follow what I've said above about the
  Apache http server.  The distinction of the "+" will mean very
  little to Fedora users (and in-fact may make the package
  more-difficult to identify) unless there is more than one HylaFAX
  package being distributed by Fedora (say, for example, separate
  "hylafax+" and "hylafax.org" packages).

Anyone else agree with that reasoning?  What about using
  Provides: hylafax 
until the hylafax.org package makes it into the distro (assuming
someone actually wants to submit it)?

The second issue is an FHS violation: several directories are
installed under /var/spool which contain things that aren't really in
the spirit of /var/spool.  There's a /var/spool/hylafax/bin directory
which, you guessed it, contains executables, a
/var/spool/hylafax/config directory containing config files, and
/var/spool/hylafax/etc containing other, different config files.

Here's what the submitter has to say (see comment 83):
  While the vast majority of HylaFAX binaries and their respective
  configuration files are installed outside of /var/spool/hylafax,
  those three directories (etc, bin, and config) are configuration
  files and configuration utility scripts, etc., that control how the
  spools are handled.

  Due to the way that HylaFAX daemons operate it would be extremely
  cumbersome (if not impossible - as in the case of a chroot) for
  these to be elsewhere.  They're very much like the configuration
  files that LPRng had under /var/spool/lpd.

  So, that's my argument.  I hope that it's acceptable.  But if it's
  not...  unfortunately there's not much that I am willing to do about
  it.

Now, lprng isn't in the distro and I really don't think it would have
passed review like that, so I can't buy that as an argument.
"cumbersome", well, too bad I guess.  I'm not sure about a chroot.  I
mean, just fix the code to look elsewhere.  How hard could it be?

But even if, it's too hard to fix, what about a few symlinks?  (To
somewhere under /usr/libexec for the bin stuff, and somewhere under
/etc for for config and etc directories.)  Do three symlinks violate
the FHS significantly enough to cause issues?  My understanding is
that this should be OK with chroots (as long as the links are
relative.)  And how does all of this square with selinux?

I'd be appreciative of any suggestions.

 - J<