In addition to my bug report:
When dpkg and logrotate were developed (1995-1998), I can imagine why
sequential numbering was chosen over date-based filenames:
Systems were typically:
- Updated offline via diskette/CD-R
- No NTP standard (xntpd experimental, ntpd 1995)
- CMOS clocks drifted ±30min/day (battery failure = years off)
- No internet connectivity for time sync
Date-based logs would fail:
dpkg-1997-12-03.log # System clock 2 weeks behind
→ grep dpkg-1997-*.log → Chaos!
logrotate solved this elegantly:
dpkg.log → dpkg.log.1 → dpkg.log.2 # Cron/timer-based, clock-independent
But in 2025 most systems are always online and NTP sync is available:
- Always-online + systemd-timesyncd (default since 2015)
- NTP sync ±1-5s
- RTC precision + hwclock -s at boot
With one exception:
Offline Edge Cases (1%): In this case logrotate remains superior
Air-gapped systems still exist:
- Military/government servers
- Nuclear/SCADA controllers
- Industrial manufacturing
- Research physics experiments
These receive USB/SSD updates with potentially weeks-off clocks.
It is, however, possible to correct the clock setting in offline systems
using a radio-controlled clock.
I therefore extend my proposal to include a dual-mode solution:
# /etc/default/dpkg-logging
USE_SYMLINK_LOGS="auto" # Default: detect NTP
# →
# Online: new date based symlink solution
# Offline: logrotate
if systemctl is-active --quiet systemd-timesyncd; then
# NTP active → symlink
else
# Offline → /etc/logrotate.d/dpkg enabled
fi
Benefits of hybrid approach:
✅ 99% Online: dpkg-trixie-2025-12.log (readable, unlimited)
✅ 1% Offline: dpkg.log.1 (clock-proof)
✅ Migration: Both systems parallel
✅ Embedded: Minimal overhead
This respects the 28-year design decision while embracing 2025 reality.
Regards,
Oliver C.
