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