Re: Bug#1108665: override: cron:admin/optional

[Alexandre Detiste <alexandre.detiste@gmail.com>]

Le mer. 2 juil. 2025 à 17:35, Chris Hofstaedtler <zeha@debian.org> a écrit :
> > Without any particular hat: I would expect someone wanting to drop cron
> > to come up with some analysis of what remains to be done and what is
> > going to break if that were to be implemented.

Hi, this has been on the back burner for me for 10 years
and наб did a systematical analysis of all the /etc/cron.... files
shipped by every single package of the distribution.

The result are the two heuristics table listed here:
   https://wiki.debian.org/systemd-cron

For the other cron jobs it is assumed that the bare name
matches the bare name of the timer.

To check one system in particular, one needs to do

# apt install systemd-cron -y;  systemctl list-timers

This will list two families of .timers :
 - the native ones.
   very common examples:
        * dpkg-db-backupt.timer,
        * man-db.timer,
        * apt-daily.timer,
        * fstrim.timer
        * e2scrub_all.timer
        * ...
- the remaining generated one, from the /etc/cron* files:
   they all live in the cron-xxxxx.timer namespace
   and physicaly in /run/systemd/generator/
        *  cron-daily-aptitude.timer
        *  cron-daily-popularity-contest.timer
        *  cron-daily-google-chrome.timer
        *  cron-monthly-check-dfsg-status.timer
        * ...

Here the non free google-chrome-stable package is the only thing expecting
a cron daemon to be there somehow and going to _break_ a little if
it's not there.

All the packages from the distribution seems to have
the proprer "Depends: cron | cron-daemon" and won't break.

I still think systemd-cron would be a better default for task-laptop;
because it is said that traditional cron or the one in Debian would wake up
the system every single minute to poll /etc
& /var/lip/spool/cron/crontabs which is bad. I don't have hard proof for this.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915370#101


> Relatedly, cron Recommends: default-mta | mail-transport-agent,
> which we kinda also no longer expect to be installed by default on a
> default install anymore. Due to how debootstrap works today, the
> Recommends: is very often not fulfilled. Nevertheless I doubt we
> still expect an MTA to be part of the default install.

That's the reason why systemd-cron Suggests: a MTA
instead of Recommending one; so that people
doing the switch do not get an extra MTA they don't what.
If they wanted one they would have installed it already.

A pre-installed MTA is fully supported.

Greetings