On Mon, 27 May 2024 at 13:59, Simon McVittie <s...@debian.org> wrote: > > On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote: > > The list of affected packages according to apt-cache showpkg is not > > that long either: > > > > anacron > > approx > > fail2ban > > fwlogwatch > > heartbeat > > hippotat-server > > inetutils-ftpd > > inetutils-inetd > > inetutils-talkd > > inetutils-telnetd > > ldirectord > > logcheck > > lyskom-server > > prelude-lml > > psad > > request-tracker4 > > request-tracker5 > > rlinetd > > snort > > socklog-run > > socklog-run:i386 > > spamd > > sympa > > xinetd > > xwatch > > zoneminder > > I think we can divide these into: packages that want to write to a logging > service via the syslog protocol, and packages that want to read a > traditional plain-text syslog file. > > For packages that want to write out messages via syslog(3) or equivalent > and have them get written out somewhere that the sysadmin can see them, > I agree that the systemd Journal (whether persistent or volatile) is > sufficient to provide a suitable log sink. Obviously many sysadmins will > want these messages to persist across a reboot, but that's a configuration > choice, for which I think defaulting to persistent but allowing volatile > at the sysadmin's own risk is a good arrangement. > > However, for packages that want to read a traditional /var/log/syslog > or similar, notably logcheck, I think it might still make sense to declare > a dependency on system-log-daemon - this is not functionality that the > systemd Journal provides. Obviously the same information exists and can > be retrieved by journalctl(1) or via libsystemd, or received and written > out to the traditional flat file over time by rsyslog or equivalent, > but it's no longer provided as a flat file on disk by default.
Yes this sounds reasonable - do you already have an idea about which is which, from the list above? And it's fine if the answer is no, I can look it up myself, just in case you already know about some of those.
