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
