Hi, On Fri, Oct 11, 2024 at 10:46:47AM +0100, Ian Jackson wrote: > Hi. Earlier this year I was asked [#1072021] to remove > Recommends: ... system-log-daemon > from one of my packages. There are some explanations here: > [0]: https://lists.debian.org/debian-devel/2024/05/msg00425.html > https://lists.debian.org/debian-devel/2024/05/msg00436.html > > The effect of making this change is that on non-systemd systems, > nothing pulls in a syslog daemon and no logging takes place. > This seems wrong.
I agree that the proposed solution is less than ideal. > Because the syslog daemon is a singleton, implementors of the virtual > package should Conflict/Provide. Therefore, to avoid apt trying to > deinstall systemd, the parts of the systemd.deb that provide this > functionality (or enable it) should be split out into a separate > package - ie systemd should own and listen on the standard syslog > socket iff that package is installed. That is how multiple > mutually-exclusive provisions of of the same facility are done in > Debian. As far as I understand things, this characterization is no longer accurate. The system-log-daemon facility used to be singleton, but the way systemd approaches it is no longer singleton. You can have: * No logging facility. * systemd-journald logging to /var/log/journal * A traditional system-log-daemon such as rsyslog running on sysvinit. * systemd-journald forwarding logs to a traditional system-log-daemon such as rsyslog. The tricky part here is that journald kinda implements what packages expect from the system-log-daemon virtual package but at the same time, it does not conflict with other system-log-daemons due to the message forwarding. > This option was rejected by the MBF proposal on the grounds that > > > splitting journald or its configuration to separate packages is not > > an acceptable workaround, as keeping enabled it by default is the > > goal > [0] I can relate to this view in the sense that journald is tightly coupled into systemd and that operating a systemd-as-pid-1 without journald is not something that can be expected to work. > This doesn't seem to make sense since packages can be installed by > default, so it would be possible to split the package and and retain > the intended behaviour in the default install. In such a split, systemd-sysv would likely depend on journald and as such exclude any other system-log-daemon, but they are meant to be able to coexist. > So it seems to me that there is no reason why systemd's syslog > functionality couldn't follow Policy, use the virtual package as > intended. It should do so, and all changes made as a result of the > MBF should be reverted. systemd-journald would like to provide system-log-daemon without excluding another system-log-daemon. Our mechanism for multiple providers very much assumes the singleton approach that systemd would to not follow as systemd maintainers consider coexistence of journald with another system-log-daemon an important feature. I'm not sure what the solution is, but the current system-log-daemon implementation doesn't cut it. > Perhaps there are some other reasons, why this is not feasible or > desirable. In that case, we should still arrange that systems which > do *not* have systemd, still end up with a syslog daemon when > required. > > Simon McVitte had a suggestion how this might be achieved [2] > but this was not embodied in the MBF. Either the reference is wrong or the attribution should be Simon Richter. The proposal is to update system-log-daemon dependencies to "systemd-sysv | system-log-daemon" and that is something that cover the relevant use cases of running systemd-only, sysvinit with system-log-daemon and systemd with forwarding to a system-log-daemon. It feels a bit annoying to have to encode systemd-sysv here, but on a technical level, that's what we want to express here. I fear what is required here is design work. In principle, we could add another virtual package dev-log-socket. It would be provided by systemd-sysv and any system-log-daemon, but without declaring Conflicts. Then all dependencies on system-log-daemon that merely require /dev/log to be captured into storage (which I expect most to be) can switch their dependency to dev-log-socket. I also feel like the problem at hand is a bit academic in nature. The vast majority of Debian installations are running systemd as pid 1 and journald with a persistent journal (by default). The system-log-daemon facility is therefore available by default in the vast majority of installations. In the container case, neither installing systemd-sysv nor a system-log-daemon provider tends to help as no services are being started (Simon Richter pointed this out). In the non-systemd case, an administrator will manually install a system-log-daemon in all but unusual situations. The ability to not install a system-log-daemon (or systemd-sysv) even when formally required (e.g. by forwarding the /dev/log socket from a container to an external journald process) seems like a benefit to me as it adds flexibility while not impacting the common case. > In any case, Policy should be updated rather than bypassed. I would like to agree, but Policy only mentions system-log-daemon in virtual-package-names-list.yaml: | - name: system-log-daemon | description: a daemon that provides a logging facility for other applications This description still feels accurate except that journald cannot provide for the sake of supporting coexistence. As a result, I am not sure what change could be effected here to resolve Ian's concern. > On a previous occasion when I brought a matter to the TC, I was > subjected to a sustained campaign of harassment, on the TC mailing > list, which Debian's authorities collectively allowed to continue. > THe harassers included full Debian members and one of the proponents > of the present MBF. Therefore: please do not email me any further > about this subject, until a TC decision is made. When Policy is > updated, I will change my packages accordingly. In the meantime, I'll > adjust my mail filters to discard messages to this bug. I see how Ian had a bad experience earlier. His refusal to interact with opponents vaguely makes sense on those ground, but doesn't help the matter. His refusal to interact with CTTE members removes our ability to solicit feedback in order to resolve the matter. Therefore I suggest that we completely turn down the request on procedural grounds: Either he is willing to discuss the matter with us (not with systemd people) or we cannot help resolve it. I am intentionally not taking ownership (in the sense of our moderation procedure) of this bug as my availability is limited during the next weeks. Helmut
