Hi Sean, On Mon, Oct 28, 2024 at 04:37:06PM +0800, Sean Whitton wrote: > I think I see a way to distinguish these four cases in a way that gets > everyone what they want. > > systemd adds an *empty* binary package > Package: systemd-journald-is-syslog > Provides/Conflicts: system-log-daemon
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. Helmut
