On Mon, 27 May 2024 at 21:38:07 +0900, Simon Richter wrote:
> My train of thought here is that there should be a "syslogd-is-journald"
> package that Provides/Conflicts system-log-daemon
...
> hence the idea to use systemd-sysv instead of a new empty
> package as the alternative
I wonderered about this too.
There is an issue with this which is unique to the journald/syslog
case. We actively don't want systemd-sysv to have Provides/Conflicts on
system-log-daemon, because as I've tried to clarify elsewhere in this
thread, there are use-cases where people will want to co-install systemd
and a traditional flat-file syslog implementation, in order to have the
logging pipeline that was the default in Debian 11:
service --> syslog(3) --> journald --> rsyslogd --> flat text files
|
\--> binary storage
(on tmpfs or disk, your choice)
because some of their tools or workflows rely on having a flat text
file, or because they value the redundancy and lack-of-structure of a
flat text file for better ability to recover partial information from
a corrupted log.
So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).
Along similar lines, I have wondered about
dbus-{system,session}-bus-is-external packages as non-default providers
of dbus-{system,session}-bus, for use in containers that arrange for a
suitable socket to be bind-mounted in from outside, but I'm unsure how
much appetite there is for a proliferation of packages whose metadata
is larger than their content for purposes like these - especially if
they could accidentally get installed (possibly on real systems rather
than in containers) by users who have not actually made the documented
arrangements, resulting in spurious bug reports and extra support burden.
smcv
