Hi Matthew (2024.12.20_13:31:33_-0400) > 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 > D > A > C I am persuaded by Helmut's rationale for voting A below N. I'm not saying that it's not an acceptable outcome. But, practically, I don't see any thing to be gained by this option winning, without the systemd maintainers following through with packaging changes to support it. And this is overriding them, so it would benefit from engagement with them. D works better with the involvement of the systemd maintainers, without their changes, the typical Debian system would end up with systemd + a non-journal syslog, which isn't optimal default. Thus I vote it below N, too. While system-log-daemon is named as a virtual package in Policy, I don't see that as policy taking any strong ownership of it. Rather I see policy documents the existence of this virtual package, and instructs packages to use it "where appropriate". Thus I vote C last. This leaves B as the only acceptable option. The container case is compelling. I think it's expected for systems to have logging available, and init systemsi without built-in logging should probably depend on system-log-daemon. This is not specified in the option (sorry, I didn't catch this problem at the draft stage), but it's the logical outcome. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
signature.asc
Description: PGP signature
