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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
