[Bug 188542] Review Request: hylafax

Sat May 24 23:16:40 UTC 2008

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: hylafax

https://bugzilla.redhat.com/show_bug.cgi?id=188542

------- Additional Comments From faxguy at howardsilvan.com  2008-05-24 19:16 EST -------
Jason and Tom, thank you very much for your assistance here.

Here are new SPEC and SRPM files:

SPEC: http://downloads.sourceforge.net/hylafax/hylafax.spec
SRPM: http://downloads.sourceforge.net/hylafax/hylafax-5.2.5-1.src.rpm

As for the hylafax/hylafax+ issue.  Nothing has changed there.  In all truth
they're pretty much the same thing.  They are nearly interchangeable.  I fully
expect those at hylafax.org to continue to claim that HylaFAX+ is a "fork" and
needs to be clearly distinguished from their releases, however, HylaFAX+
frequently and routinely serves as the upstream for development for their
codebase (and vice-versa).  There are some differences, but it's truthfully no
more difference than exists between, say, Apache HTTPD from Debian and Apache
HTTPD from Fedora.

Whether or not the package should be called "hylafax" or "hylafax+"... I really
don't care much.  My preference is to leave it as "hylafax" since users who are
using old "hylafax" RPMs from hylafax.org should be able to seamlessly upgrade
with 'rpm -Uvh' without noticing much beyond the usual.

The tarball in the src.rpm did not match the tarball from the Source0 URL
because in going to hylafax-5.2.4-3.src.rpm from hylafax-5.2.4-1.src.rpm (in
order to address Fedora 9 issues mentioned above) I made changes to the tarball
in the src.rpm without cutting another release of the tarball indicated in the
Source0 URL.  From now on I'll apply patches instead of changing the tarball on
-2, -3, -4, etc releases.

I removed /etc/hylafax/faxcover_example_sgi.ps from the upstream repository. 
Thank you for pointing out the lack of fair use.

In future releases I will not point to a specific Sourceforge mirror in Source0
but will instead point to downloads.sourceforge.net.  For this release I left it
pointed at the specific URL.  Thanks for pointing this out.

I've removed the name of the package from the summary.

I've changed License to "libtiff and BSD with advertising"

I've fixed the formatting of the changelog entries (although I neglected to make
one for this release).

I've added a dependency on crontabs.

I've added dependencies on /sbin/ldconfig.

As for the stuff going in under /var/spool... I'm afraid that's something that I
cannot change.  Changing it upstream would be a support nightmare, and so would
having the Fedora distribution be so vastly different from the rest of the
HylaFAX installations out there.  It's been this way for 18 years now, and
moving hylafax from /var/spool at this point due to perceived incongruities with
FHS is just something that I'm not anxious to do.  The benefits of having
HylaFAX in Fedora would not likely outweigh the costs of dealing with the
subsequent support nightmare that would ensue.

That said, let me make my argument as to why everything under /var/spool/hylafax
should be acceptable as it is.

The purpose of /var is to allow /usr to be read-only.  Thus, any files that are
subject to change during normal application function are expected to reside in
/var.  Strictly speaking /var/spool is reserved for files that are to be
processed in the future.  Thus, the bona-fide spools are totally legit:
/var/spool/hylafax/sendq, hylafax/doneq, hylafax/recvq, hylafax/status,
hylafax/log, hylafax/info, etc.  In fact, the only directories that are not
technically spools are hylafax/etc, hylafax/bin, and hylafax/config.

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.

I do thank you and appreciate your attention.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.