Bug#1084924: The system-log-daemon virtual package

[Helmut Grohne]

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