Hi,

in a discussion today on IRC #debian-devel, it was mentioned that
cron is "important". However during the trixie development cycle,
many more packages started installing systemd timer units.
On a default install, I would therefore argue that cron is no longer
very important.

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.

Thanks,
Chris

Hi,

Chris Hofstädtler <zeha@debian.org> (2025-07-02):

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.

Also, at this stage of the release cycle, really?

Cc-ing debian-devel@ so that this gets discussed there.


Cheers,

I pondered that, but packages have to depend on cron anyway if they
want it. cron is not Essential: yes.

Seemed like reconsidering the cron prio was forgotten, but from my
PoV it doesn't matter if it happens for trixie or forky.

Thanks.

Chris

Le mer. 2 juil. 2025 à 17:35, Chris Hofstaedtler <zeha@debian.org> a écrit :
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
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

I would like to note that (a) "drop cron" implies
"not having a cron daemon at all" which means an obviously broken system;
sd-cron is an implementation of the cron daemon, which (b) I've been
successfully using exclusively, entirely uneventfully in spite of my
best efforts, for, now, years, on every class of system.

I'd also argue that root mail is likewise a necessity for well-functioning
systems but that's harder to sell in 2025; either way, sd-cron's Suggests:
reflects reality ‒ it can send you mail if you want or it can not,
and you get the failures like any other service failures.
or it can send matrix messages. or whatever via apprise.

Best,

Le Thu, 03 Jul 2025 22:17:44 +0100,
Richard Lewis <richard.lewis.debian@googlemail.com> a écrit :
packages set, to reduce the size of some setups.

Dropping cron from the Debian archive would cause a lot of problems, but I
don’t think this is what is discussed here.

* Richard Lewis <richard.lewis.debian@googlemail.com> [250703 23:18]:
  Subject: and actually the quoted context.

The point was lowering the Priority: from important to optional.

Chris