Hello, On Mon 28 Oct 2024 at 11:04am +01, Helmut Grohne wrote:
> Thank you for bringing this up. Despite the little confusion in the end > that Chris remarked, I think this practically covers the four cases. > > However, I think there is a fifth case that is becoming more and more > practically relevant. Both docker and podman now have a logging driver > called journald. > > https://docs.docker.com/engine/logging/drivers/journald/ > > I'm not yet sure exactly how this works, but the context is "slim" > containers (i.e. those that do not run systemd as pid 1) and I very much > expect them to not run a journald from the container environment either. > Rather the container runtime essentially provides /dev/log and a > journald socket to the container in some (unspecified?) way. > > This kinda is similar to dbconfig where we have dbconfig-no-thanks. We'd > need another package syslog-no-thanks that would have the same provides > and conflicts but no systemd dependency now. > > Of course just adding such a package would result in apt selecting it > whenever systemd is difficult to install. In effect, adding such a > package would render dependencies on system-log-daemon meaningless and > we could just drop them - which is what has been happening and has > resulted in this bug. > > So now we're running in circles. Effectively, we must decide whether the > container use case is more important than the non-systemd case or the > other way round. I do not see a way to make both just work in a sane > way. I think I understand what you mean about why a syslog-no-thanks virtual package would not be helpful, but I don't understand how the journald driver option interacts with my four options. How do systemd and these journald drivers interact? Aren't we in case #1? -- Sean Whitton
signature.asc
Description: PGP signature
