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

[Helmut Grohne]

Hi Sean,

On Fri, Nov 08, 2024 at 07:01:24PM +0800, Sean Whitton wrote:
> Hello,
> 
> On Thu 07 Nov 2024 at 11:03am +01, Helmut Grohne wrote:
> > 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.
> 
> I read your previous message again and I think I understand the example
> a bit better now.

I am relieved to see that our disagreement is rooted in
misunderstanding.

> So, these super-slim containers don't have systemd installed at all, so
> systemd can't provide the virtual package inside them, right?

I confirm. I would not call such containers super-slim though. The main
distinction I've seen is into "fat" or "system" containers where there
is a process with pid 1 (commonly systemd) doing service supervision
inside the container and "application" container where the actual
application is the only process (group) inside the container (either as
pid 1 or with a minimalistic supervisor provided by the container
runtime). Essentially, any kind of bubblewrap, flatpak, snap, as well as
most use of docker/podman fall into this latter category. We don't
expect the systemd binary package to be installed in such containers and
if it happens to be, we don't expect systemd to run as pid 1.

Does this add clarity?

I would also like to observer that Build-Depends: system-log-daemon will
commonly get you an environment that lack logging services.

> Also, sorry -- what exactly do you mean when you say "the exclusion
> mechanism"?

In my understanding, system-log-daemon virtual package originally served
two distinct purposes:

 1. If you depend on it, then you can assume that messages emitted using
    syslog(3) or written to /dev/log are handled in some means.
 2. The dependency system prevents two implementations of a /dev/log
    handling service from being installed at the same time.

When I say "exclusion mechanism" I refer to the second purpose. My
understanding of the conversation thus far is that we have broad
consensus for continued use of the virtual package for preventing
coinstallation of two logging services (2) while we have some
disagreement about how to express a requirement on logging services to
be available (1).

Helmut