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=188542 --- Comment #120 from Lee Howard <faxguy@xxxxxxxxxxxxxxxx> 2011-10-26 03:33:00 EDT --- While I'm not averse to creating man pages for every executable installed, I remain unconvinced and highly sceptical that doing so for executables not designed to be run by users would have any meaningful value. Even in a minimal install Fedora has very numerous executables installed which do not have man pages, and as a Fedora use I have never once have wanted to run those executables directly or have been disappointed by there not being a man page for them. Not everything that utilizes files and scripts from the traditional /var/spool/hylafax directory operates within the chroot, and so renaming that "spool" directory to /var/hylafax/chroot is misleading. I would be agreeable to move it to /var/hylafax. I think that this was suggested before in Comment #94. However, both this and your suggestion seems to violate the FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE31 "Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list." For what it may be worth, the contents of the "HylaFAX spool" directory are as follows: drwx------ 2 uucp uucp 4096 2010-05-02 20:50 archive drwxr-xr-x 3 root root 4096 2010-07-30 15:41 bin drwxr-xr-x 2 uucp uucp 4096 2011-10-25 11:08 client drwxr-xr-x 2 root root 4096 2010-07-30 15:41 config drwxr-xr-x 2 root root 4096 2010-05-02 20:50 dev drwx------ 2 uucp uucp 4096 2011-10-25 13:01 docq drwx------ 2 uucp uucp 4096 2011-10-25 12:01 doneq drwxr-xr-x 2 uucp uucp 4096 2011-10-25 03:47 etc drwxr-xr-x 2 uucp uucp 4096 2011-10-25 11:08 info drwxr-xr-x 2 uucp uucp 77824 2011-10-25 16:55 log drwx------ 2 uucp uucp 4096 2010-05-02 20:50 pollq drwxr-xr-x 2 uucp uucp 36864 2011-10-25 16:55 recvq drwx------ 2 uucp uucp 4096 2011-10-25 11:08 sendq drwxr-xr-x 2 uucp uucp 4096 2010-05-02 20:50 status drwx------ 2 uucp uucp 4096 2011-10-25 11:06 tmp Additionally, there are FIFOs for each modem and one for faxq created there. The directories archive, client, docq, doneq, info, log, pollq, recvq, sendq, status, and tmp are all true spool directories per the FHS definition you cite. The bin, dev, and etc directories are the ones raising concerns (and namely bin), and they all are there so that they can be accessible to the hfaxd client from within the chroot. The dev directory is there for access to /dev/null. The etc directory is there so that the administrative hfaxd client could manipulate configuration files. The bin directory is only there for needful operations within the chroot. You can maybe think of it as a type of hybrid between lpd and ftp. Imagine a printing client/driver that could send print jobs to the server but also retrieve copies of previous print jobs and change various types of operations in the print server. Recognize that HylaFAX heralds from a time 20 years ago when FHS didn't exist. So it's not like HylaFAX was developed in direct violation of FHS - rather, FHS was developed without consideration of HylaFAX. Both Gentoo and Debian have HylaFAX ports, and both have left /var/spool/hylafax there. (However, in attempting to address the FHS concern Debian has done some cumbersome synchronizing work to duplicate files from /var/spool/hylafax/bin and /var/spool/hylafax/etc into /etc/hylafax - or something like that. I'm not sure how this helps alleviate the FHS concern, though.) My perspective on this is that the FHS just does not have an appropriate categorization for service-level applications that allow client access to scripts and configuration files from within a chroot that 99% of the time is used for spool purposes. However, if moving /var/spool/hylafax to /var/hylafax will resolve the concerns, then I am willing to do that. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review