Bug#1121807: Acknowledgement (ITP: dpkg monthly named logs via symlink (replace logrotate dependency))

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.