Package: check-dfsg-status
Version: 1.32
Severity: normal

hi,

W: check-dfsg-status: missing-systemd-timer-for-cron-script 
[etc/cron.monthly/check-dfsg-status]
N: 
N:   This package ships the specified cron script but does not ship a 
equivalent systemd .timer unit.
N:   
N:   The "desktop" and "laptop" tasks no longer pull in anacron(8), the usual 
solution for desktop installations that are not running all the time.
N:   
N:   Please consider shipping an equivalent .timer file for this script.
N: 
N:   Please refer to the systemd.timer(5) manual page, the anacron(8) manual 
page, and Bug#1007257 for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: systemd

let to the following conversation on #debian-devel:

<h01ger> is there some tool to use systemd.timer files with cron (for systems 
without systemd)
<h01ger> i'm asking because https://paste.debian.net/1264393/
<      zeha> | h01ger: your idea being 'lets ship a .timer unit instead of the 
current cron job, and wrap that for non-systemd systems'?
<    ansgar> | h01ger: I think there is only "run the ExecStart= commands via 
cron, guarded by a `if` condition"
<zeha> would still be useful if that was in a package
<h01ger> or ship both and ignore the cron file when running systemd
<h01ger> or stop supporting sysv
<zeha> -d /run/systemd && exit 0 seems to be the common solution i've seen so 
far
<h01ger> i'm mostly genuinly wondering what "we want" or do.
<zeha> that seems like a loaded question :-(
<zeha> not having all that compat glue seems like it would be a lot nicer/easier
<h01ger> maybe the lintian msg needs adjusting too
<Myon> having a separate .timer unit instead of being about to throw stuff into 
a cron.monthly directly seems like a regression
<Myon> perhaps a monthly.timer would make sense?
<Myon> it could still be separate .service entries for each thingy
<waldi> Myon: how would that work? and what would it solve?
<waldi> i don't see the difference of writing one or two files files
<waldi> you could use monthly@bla.service, just to avoid providing that one 
file but have the automation that enables the timer unit now fail
<zeha> might be nicer to see all 'monthly' jobs in one go
<Myon> moi  U
<waldi> so you want to have cron.monthly, which ties everything into one blob, 
looses error reporting and all?
<waldi> does not look useful
<zeha> the .service units still have their own error reporting?
<waldi> hmm, monthly.timer -> monthly.target and bla.service 
WantedBy=monthly.target
<waldi> might work
<waldi> or not.
<Myon> something like that, yeah
<waldi> sounds fragile. as one failure to stop will make sure nothing will run 
ever again
<h01ger> based on the discussion, i think i'd go with just the timer file. and 
if^wwhen someone complains they/we can figure something out.
<h01ger> though maybe for trixie. still got a bit time to decide that.
<h01ger> zeha: ansgar: Myon: waldi: may i put this conversation in a bug 
report? (if wanted i could also replace $nick with $anon-alias123 but i'd 
rather not do that. however if you prefer..)
<waldi> sure
<     waldi> | h01ger: i'm also going to ask them to work on a generic unit to 
init.d converter. we are so good into individualizing costs
<    ansgar> | h01ger: Dine with me.
<      zeha> | h01ger: go ahead
<      Myon> | h01ger: go ahead
<h01ger> zeha: ansgar: Myon: waldi: thank you! :)


tl;dr:

<h01ger> based on the discussion, i think i'd go with just the timer file. and 
if^wwhen someone complains they/we can figure something out.
<h01ger> though maybe for trixie. still got a bit time to decide that.


-- 
cheers,
        Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Make earth cool again.

Attachment: signature.asc
Description: PGP signature

Reply via email to