Hi Matthew,
On Sun, Dec 15, 2024 at 02:02:12PM +0000, Matthew Vernon wrote:
>
> Here's a draft ballot; please suggest changes and/or say you're happy with
> it in the next couple of days, I (or someone else!) can call for votes on
> it.
Thanks for kicking of the drafting.
> ===8<===
> In Bug #1084924, the Technical Committee was asked about a mass bug filing
> that aimed to remove all dependencies (except Provides: and Conflicts:) upon
> the system-log-daemon virtual package. Whilst the wording of policy in this
> area is unclear, the Technical Committee notes that long-standing practice
> in this area as reflected by policy was that packages could declare
> appropriate dependencies upon the system-log-daemon virtual package. The
> Technical Committee also acknowledges that on systemd systems, journald can
> serve the purpose of system-log-daemon, but that systemd also supports
> installing a separate system-log-daemon.
I like your introduction on many accounts. It does a good compromise on
mentioning much of the relevant context without being very long.
> A) The Technical Committee affirms that it is reasonable for a package to
> declare any suitable dependency upon the system-log-daemon virtual package.
> The Technical Committee suggests that Policy be updated to clarify this, and
> that maintainers who removed such dependencies as a result of the mass bug
> filing consider restoring them.
This resolution does not make sense on its own to me, because the most
common case - using journald as your only logging daemon - is not
covered by this resolution. In the IRC meeting we considered augmenting
it with a systemd-journald-is-syslog dummy package that Provides:
system-log-daemon and Depends: systemd-sysv. Is there a reason of not
including this in the resolution? Separately, did we connect with
systemd developers about this package and whether we'd have to overturn
them?
> B) The Technical Committee agrees that packages should now only declare
> Provides: and Conflicts: relationships with the system-log-daemon virtual
> package, and that Debian systems may be assumed to run a syslog logger. The
> Technical Committee suggests that Policy be update to reflect this change.
Whilst this resolution sounds reasonable to me. I don't think it can be
understood in a good way without adding more context. As such, I
recommend adding a rationale section to it. I propose the following
text:
Whether logging is available no longer is a boolean. A container
runtime can provide a /dev/log service by forwarding to an external
logging service. Many systems now use journald as their only logging
daemon, but journald can also cooperate with another logging daemon.
Removing dependencies on system-log-daemon should be seen as a
recognition that the availability of a logging daemon can no longer
reasonably be expressed using the dependency system. Additionally,
most log message producers fail gracefully in the absence of a log
consumer by skipping logging.
> C) The Technical Committee resolves that this is a de facto attempt to
> change Policy, and that the Policy process should be used to consider
> whether to change Policy relating to system-log-daemon from the status quo
> of packages being able to declare any reasonable dependency upon
> system-log-daemon to the state where only Provides: and Conflicts: may be
> used. Until that process is concluded, dependencies upon the
> system-log-daemon should not be removed (unless they are incorrect on the
> merits of an individual case).
I think Ansgar's option is worth adding.
D) The Technical Committee recognizes that logging daemons can now
coexist. As a result, logging daemons should stop conflicting with
one another and systemd-sysv should gain Provides:
system-log-daemon. As the original motivation for removing
dependencies on system-log-daemon no longer applies, packages can
and should again issue dependencies on system-log-daemon where
deemed appropriate by their maintainers. The Technical Committee
suggests that Policy be updated to reflect this change.
Do you agree with these proposed changes?
Helmut
