[arch-general] Change Arch's default crond

[Grigorios Bouzakis]

Kaiting Chen wrote:
> On Apr 21, 2011, at 17:30, Grigorios Bouzakis <grbzks at xsmail.com> wrote:
>
>> Ionut Biru wrote:
>>> On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:
>>>> Ionut Biru wrote:
>>>>> On 04/21/2011 02:18 PM, Heiko Baums wrote:
>>>>>> Am Thu, 21 Apr 2011 08:48:04 +0200
>>>>>> schrieb Sven-Hendrik Haase<sh at lutzhaase.com>:
>>>>>> 
>>>>>>> I second this suggestion. cronie upstream isn't dead at all. cronie
>>>>>>> is a drop-in unlike fcron which was favored earlier.
>>>>>> 
>>>>>> Is it such a drop-in like the new dcron when dcron upstream was adopted
>>>>>> by this Arch user?
>>>>>> 
>>>>>> Better look at the features and the use cases (don't only think of some
>>>>>> 24/7 servers, but also think of the desktop users) and not at some small
>>>>>> differences in the crontab syntax. It's definitely not such a big work
>>>>>> to re-adjust a few crontab entries if this is necessary at all. And this
>>>>>> work has to be done only once and can probably be done with sed.
>>>>>> 
>>>>> 
>>>>> i think you are not understanding the process.
>>>>> 
>>>>> if cronie is moved in core, it won't have a replaces=dcron. Only new
>>>>> installations will get cronie by default instead of dcron.
>>>>> 
>>>> 
>>>> How is that possible? Are you saying that the broken dcron will stay in
>>>> core and there will two packages for cron?
>>>> Otherwise i dont understand how it wont be replaced (for all users).
>>>> 
>>> 
>>> 
>>> if this will happen, the steps are very simple
>>> 1) remove dcron from core
>>> 2) add cronie/fcron to core in base group and depending on the package, 
>>> it might have conflicts=dcron but not replaces
>>> 
>>> this way the existent systems will still have a "working" cron and new 
>>> installations will have the new cron
>>> 
>> 
>> Has that ever happened before?
>> That means the existing systems will have a package from base thats not
>> supported by the Arch developers.
>> But since its not replaced, it would make it an infinite part of Arch so
>> it should also be supported.
>> Plus, the 2010.05 ISOs will still (try to) install it, but it wont be
>> there, and there wont be an upgrade path either.
>> Anyway, first time i've heard about such a plan. It makes absolutely no
>> sense to me. I seriously doubt its gonna work. But good luck.
>> 
>> ----
>> Greg
>
> Things have got to be deprecated eventually.

If/when they cease to work, or simply don't cover people's needs,
naturally.

>Why can't we keep dcron in [core] for a while longer?
>And remove it when any install media that requires it becomes
>unsupported?

I didn't say you can't keep it in core. This discussion keeps coming up
every few months because apparently dcron doesn't work correctly so the
question should be "is there any reason to keep it?" and not the
opposite. No matter how much time 'a while longer' is you'll always have
to replace it with something that provides the same functionality in
order to avoid the stuff i wrote above.
Removing a package from the repos has happened many times before and
will happen again but its very different removing eg. catalyst than
removing a package from core, let alone base.
A package from base is a package that you assume its present on every
system. A package that part of base is obviously a very important part
of the system. You can't just remove it or choose to ignore its there.

Does dcron work? Yes? Then stick to it. No? Then replace it with
something that works.

PS. If cron is deprecated in favour of systemd which is so awesome, why
is Red Hat paying someone to work on cronie?

----
Greg