On Wed, Sep 06, 2023 at 08:54:22AM +0200, Martin Lottermoser wrote: > > The reason it does what it does exists, the cron job runs > > once a day and if you compare the timestamps directly, and > > the cron job happens to run 23:59:59 hours after the last time, > > it wouldn't execute, hence it just compares the days. > > Which is the reason why my apt configuration has included > > APT::Periodic::Update-Package-Lists "18h"; > > for some time (which only works with a modified apt.systemd.daily, of > course). > > Note that, because Debian handles activation independent of the duration > variables in APT::Periodic, the meaning of the latter is different from > what a user might naively expect after reading the documentation: while > a description like > > APT::Periodic::Download-Upgradeable-Packages "0"; > - Do "apt-get upgrade --download-only" every n-days (0=disable) > > in apt.systemd.daily suggests that these variables control activation, > they are in effect only variables to *suppress* the execution if the last > execution was too recent. > > This also means that the current implementation permits at most one > execution per calendar day; see report #778873 for an example of someone > who wanted more (which would be trivial with systemd timers, provided > apt.systemd.daily were to be modified as I proposed or one were to > abolish these variables entirely). > > > I have no intention of changing the behavior of these timestamps > > because we really need to remove them entirely and rely on systemd.timer > > execution settings, otherwise this never works reliable (and the > > cron job for non-systemd systems will retain the existing behavior > > as-is, it is a static target that should remain bug-compatible forever). > > > > But this requires splitting up the services further to reasonable levels > > of configurability and I haven't put any work into that yet. > > I have no problem with that. After all, it's FOSS, and I can modify the > files on my systems. I just thought my proposal would be useful to > others as well (besides aligning with the documentation and eliminating > one unnecessary cause of runtime errors -- oh, and trivial to implement). I have taken my time to reply to your bug, and explain to you why it's not trivial to change so please do not tell me it's trivial. It's there for a reason and the reason doesn't suddenly go away if you chose to ignore it. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature