Hylafax review issues

[Hans de Goede]

Jason L Tibbitts III wrote:
> 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?

I tend to agree that plain hylafax is the right name for a couple of reaons:
1) hylafax is quite well known so I would expect "yum install hylafax" to just
    work, but also something like rpm -q hylafax. Note that the quite well
    known-ness also is an argument to get this thing reviewed and included it
    really is a shame that Fedora currently does not have a hylafax package,
    so Jason good work on trying to get this through review!

2) When in doubt about things like Casing or cases like this I always look at
    the source tarbal name, and that in this case is plain hylafax, not hylafax+
    changing the name would mean that a -n argument would be needed to %setup,
    also notice that the installed binaries, service, etc are all called hylafax
    without the +.

> 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.
> 
> 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 tend to agree with you on this one, but having just packaged coda I know how 
non FHS compliant locations can sometimes be hardcoded all over the place (no 
not as easy as a singel define somewhere, paths written fully all over the place).

So I'm somewhat sympathetic to the submitters arguments, have you suggested the 
symlink approach to him?

Regards,

Hans