Bug#1084924: Call for votes

Helmut Grohne <[email protected]> Fri, 20 Dec 2024 23:03:54 +0100
Newsgroups	gmane.linux.debian.devel.ctte
Message-ID	<20241220220354.GA2271181__34184.2445240886$1734732577$gmane$org@subdivi.de>
On Fri, Dec 20, 2024 at 05:31:33PM +0000, Matthew Vernon wrote:
> 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.
> 
> A) The Technical Committee affirms that it is reasonable for a package to
> declare any suitable dependency upon the system-log-daemon virtual package.
> As journald can serve as system-log-daemon either alone or alongside a
> separate system-log-daemon, this should be expressed in the systemd
> packaging, by shipping a systemd-journald-is-syslog dummy package or some
> other suitable mechanism. 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.
> 
> B) The Technical Committee notes that logging may be provided by a container
> runtime, or by journald (by itself or in concert with a separate
> system-log-daemon), and that it is no longer practical to express the
> availability or otherwise of a logging daemon via package dependencies.
> Therefore, the Technical Committee agrees that packages should now only
> declare Provides: and Conflicts: relationships with the system-log-daemon
> virtual package. The Technical Committee suggests that Policy be update to
> reflect this change.
> 
> 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).
> 
> D) The Technical Committee notes that logging daemons can now co-exist with
> each other. Therefore, they should stop conflicting with one another, and
> systemd-sysv should now Provides: system-log-daemon. Given this change,
> 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.
> 
> N) None of the above / Further Discussion.

I vote

    B > N > C > A = D

Rationale:

I cannot vote A or D above N, because both of them override systemd
maintainers without - in my view - having seeked their feedback in a
sufficient manner. My understanding is that both A and D require a
3:1 majority under constitution 6.1.4.

I strongly favour B for the reasons given in my earlier mail. No other
proposal simultaneously supports all use cases. Options A and D fail at
serving the container use case (where logging is provided externally).

C is effectively giving up on deciding the matter. I rather see us
taking another round and trying to reach a conclusion (after contacting
systemd maintainers) than punting on the decision. Deferring it to
policy maintainers.

Helmut
signature.asc (application/pgp-signature, 833 B)