IMHO there are several issues regarding the current fcron-ebuild: First of all, the manpages state the location of the fcron configuration files as "/usr/local/etc", that's a trivial issue. Second, in my opinion fcron.allow and fcron.deny should be left out since gentoo has the "cron"-group and fcron.conf should be placed it its standard location in /etc. Whoever wishes to use this feature needs to write his own files anyway so why have them in the first place? I know this issue is a matter of taste but IMHO gentoo should be clean & simple. Third, please do do not hard-code the /etc/fcron/-directory. It is already changed in the initscript and I don't want to feel like I'm running SuSE. By the way: Why does the standard initscript need support for running several fcrons in parallel but all as root? Reproducible: Always Steps to Reproduce: 1. $ strings /usr/sbin/fcron | grep fcron.conf Actual Results: /etc/fcron/fcron.conf Expected Results: /etc/fcron.conf
(In reply to comment #0) > First of all, the manpages state the location of the fcron configuration files > as "/usr/local/etc", that's a trivial issue. Thanks, I'll fix that. > Second, in my opinion fcron.allow and fcron.deny should be left out since > gentoo has the "cron"-group and fcron.conf should be placed it its standard > location in /etc. Whoever wishes to use this feature needs to write his own > files anyway so why have them in the first place? > I know this issue is a matter of taste but IMHO gentoo should be clean & > simple. /etc/fcron/fcron.conf: It has been that way on Gentoo for a long time and I'm not going to bother users with a completely useless change they'd have to take care of on an update. /etc/fcron/fcron.{allow,deny}: fcron has a different security model compared to vixie-cron. If you don't like it then don't use it or talk to upstream. > Third, please do do not hard-code the /etc/fcron/-directory. It is already > changed in the initscript and I don't want to feel like I'm running SuSE. Hard-code? Where? You should actually *mention* what you are talking about. Thanks. > By the way: Why does the standard initscript need support for running several > fcrons in parallel but all as root? /etc/init.d/ scripts are for system (not user) instances of services/daemons and those are usually run as root. If you don't need multiple instances of fcron then just don't use that feature.
> It has been that way on Gentoo for a long time and I'm not > going to bother users with a completely useless change they'd > have to take care of on an update. I'm aware that reverting this non-standard location is probably not worth the trouble. As I said, this is a matter of taste. > Hard-code? Where? You should actually *mention* what you are talking about. > Thanks See original description. Since --sysconfdir=/etc/fcron is used as option to ./configure, one ends up having /etc/fcron/ compiled in as standard location for fcron.conf and friends while the documentation states otherwise. Although I'd like it better to be /etc/fcron.{conf|allow|deny}, I fear it's easier and cleaner to patch the manpages than to introduce two different ETC variables for compiling and installing. > If you don't need multiple instances of fcron then just don't use that > feature. As far as I can see, this is only useful for a weird chroot-setup and shouldn't be in a default initscript (there's a reason why gentoo boots so slow...) but I know that you won't remove it after all the time.
(In reply to comment #2) > > Hard-code? Where? You should actually *mention* what you are talking about. > > Thanks > > See original description. Since --sysconfdir=/etc/fcron is used as option to > ./configure, one ends up having /etc/fcron/ compiled in as standard location > for fcron.conf and friends while the documentation states otherwise. As I said, I'll fix the *manpages*, as they are the part which is wrong, not the rest. > Although I'd like it better to be /etc/fcron.{conf|allow|deny}, I fear it's > easier and cleaner to patch the manpages than to introduce two different ETC > variables for compiling and installing. Whatever... > > If you don't need multiple instances of fcron then just don't use that > > feature. > > As far as I can see, this is only useful for a weird chroot-setup and > shouldn't be in a default initscript No, there are other reasons for which one may want to be able to use different instances (think of different softlevels). > (there's a reason why gentoo boots > so slow...) but I know that you won't remove it after all the time. You want to tell me that multiple instances support of /etc/init.d/fcron slows down the boot process due to 2x grep+sed? Come on!
> No, there are other reasons for which one may want to be able to use > different instances (think of different softlevels). You're right, this laptop runlevel thing comes to mind... > You want to tell me that multiple instances support of /etc/init.d/fcron > slows down the boot process due to 2x grep+sed? Come on! No, it's just a small part of the huge mess of sys-v-init shellcode. Gentoo init is a slow by design and it gets even worse because everyone checks for every possible error. While this has some benefits for beginners, I personally like minit[1] much better, it is magnitudes faster and on a server you can't see pretty output anyway. But that's not the subject now, thank you for your time. [1] http://www.fefe.de/minit/
*** Bug 264201 has been marked as a duplicate of this bug. ***
Documentation now is updated for the correct installation paths.
