Hi Sean, On Thu, Nov 07, 2024 at 10:37:22AM +0800, Sean Whitton wrote: > Helmut, I think my conversation with you is somewhat verging into > detailed design work. We don't want the TC to be trying to decide > exactly what sort of containers we want to support; we just want to be > sure we're not definitely blocking anything we don't want to > definitively block.
I respectfully disagree with your characterization. I used the podman example to demonstrate actual use of the underlying concept that a container runtime would be responsible for providing logging services and concluded that a dependency on logging services would no longer be expressible in our dependency system. To me, this is not yet design work. Rather we would be shifting to a state where logging services are always assumed available and all that we would continue to maintain is the exclusion mechanism. > So, I think my proposal (to the extent it too is not design work) still > stands as a resolution to the bug. I'll write to Ian about it off-list > to see if he agrees. I have little doubts that Ian would agree with your proposal. I do have severe doubts that systemd maintainers would agree with it though. So the ones to talk to first would be systemd maintainers in my view. Given my current understanding of the matter, I'd vote your proposal below NOTA, because I think that it leaves an important use case unaddressed. Indeed, we can lift Bastian's mail into a proper proposal. Logging services are generally assumed to be available. It becomes the responsibility of the init system or container runtime. The system-log-daemon virtual package mainly serves as an exclusion mechanism. Alternative init systems such as sysvinit-core should issue a dependency or recommendation on it. Helmut
