Noah Meyerhans <no...@debian.org> writes: > On Wed, Jan 08, 2020 at 02:43:08AM +0100, Daniel Leidert wrote:
>> I disagree here. I don't want you to overrule my decision for a >> cron-script. If a user has enabled a cron-job you shouldn't change that >> to a systemd timer unit without the user's explicit approval. > I'm not sure that I take CRON=1 as meaning "I want to use cron forever". > I'd rather interpret it as "I want to enable spamassassin's daily > maintenance job". The details of how it's accomplished aren't really > relevant, IMO. Yeah, that's my reaction as well. The point is to run the job periodically. A timer unit is easier to enable and disable. I think most users (I'm one) will not care about how this is done. The one exception I can think of is if someone really wants to customize the job. That can be a little more tedious to do with timer units. Right now, I think there's a bunch of logic in the /etc/cron.daily script that someone could in theory change. But I'm not sure how often that happens or how useful that would be. > Yeah, that's probably the best way in terms of user flexibility. I'm > not convinced it's necessary, though, and I don't like the idea of all > the other packages undergoing similar transitions all having to > introduce similar debconf questions. I share your dubiousness that adding tons of debconf prompts for cases like this (there are likely to be a bunch of them) makes sense. Thank you for raising this! I'm watching the thread closely since I think the conclusions here should probably end up in Policy at least in part. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>