Am Thu, 21 Apr 2011 21:07:35 -0400 schrieb Kaiting Chen <kaitocracy@gmail.com>:

First of all the cronie in [community-testing] is compiled with --enable-anacron. It installs not only an /etc/crontab but also an /etc/anacrontab. Scripts in '/etc/cron.hourly' are run directly by `/usr/sbin/crond` while scripts in '/etc/cron.daily', '/etc/cron.weekly', and '/etc/cron.monthly' are run by indirectly by `/usr/sbin/crond` through `/usr/sbin/anacron`.

And this is one of the main problems with cronie. It needs a separate /etc/anacrontab for anacron jobs. And this makes it more complicated as necessary. Fcron only needs one fcrontab for every job. To use the anacron feature it just needs to be added a "&bootrun" in front of the line. This way tasks are run as usual cron jobs if the system is up and as anacron jobs if the system is down. This fits all needs in one, the needs of 24/7 servers and the needs of desktop systems. Cronie is nothing else than two different daemons, cron and anacron, put into one binary but with exactly the same complicated functionality and configuration. And the scripts in /etc/cron.{hourly,daily,weekly,monthly} are run directly by fcron, too. And by default there is a "&bootrun" in front of the fcrontab lines which tell fcron when to run those scripts. Another point: fcron is very well documented while there's no documentation about cronie, not even a feature list and comparison. Heiko

Kaiting Chen wrote:

[...] Second cronie will in no way `replaces=('dcron')` but will most likely `conflicts=('dcron')`. Therefore while it will be impossible to install both on the same system having cronie in [core] will in no way force existing users to switch.

[...] Next it is absolutely not the case that every package in 'base' is critical to the operation of a machine. For example 'reiserfsprogs' is in 'base' but unless you have a ReiserFS filesystem then you don't need it. Every package in 'base' is however installed by default.

Why do you say "cronie will in no way replaces=('dcron')" ? If you say that cause it isn't a drop-in replacement and users will have to adjust their crontab entries, that's wrong and this is why. Here's a better example than reiserfsprogs. Bootloaders. There are three of them in core (grub,lilo and syslinux) and grub2 in extra but only one of them in base (grub). Almost everyone needs a bootloader, like almost everyone needs a cron handler. There is the default (grub) and there are three additional ones available to accomodate users different needs. No matter what happens to lilo syslinux and grub2, if grub for whatever reason were to be removed, it would always have to be replaced by something as the default bootloader. What would replace grub? Nothing that could replace it would be a drop-in replacement and users would have to fiddle with its configuration to fit their needs and get the same result they had before. It would also in any case be different than grub. Arch is a DIY rolling release distribution and you may occasionally find yourself in such situation. It's inevitable. What's most important is a clean upgrade path for existing users and striving to avoid finding yourself into such an uncomfortable position repeatedly by making the wiser choices you can along the run. Even Debian which uses more automagic stuff in order to provide the users with choices in package selection and automatic package substitution as well as configuration, provides some default from which you can later switch to something else. Something *should* be the default and since the current default doesn't work, something else should replace it. Even if both cron implementions that are on the table went into core, one of them will have to go to base to replace dcron. Even if changing the crontab configuration again annoys everyone. ---- Greg