Package: tech-ctte Control: block 1072021 by -1 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. Also, I notice that this MBF proposal appears to have had no involvement with the Policy process even though it, effectively, amounts to the abolition of the system-log-daemon virtual package, which is, of course, established by Policy [1]. It seems to me that the semantics of the "system-log-daemon" virtual package must mean "there is a syslog service". Since systemd is capable of being a syslog service, that means that it should Provide that virtual package. 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. 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] 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. 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. 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. In any case, Policy should be updated rather than bypassed. Please would the TC reaffirm policy, and give appropriate advice. Alternatively, if policy needs to change please would the TC assist this process, and help ensure that the resulting policy (i) suits the needs of all Debian configurations (ii) is properly documented (iii) is implemented. 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. Ian. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#relationships-between-source-and-binary-packages-build-depends-build-depends-indep-build-depends-arch-build-conflicts-build-conflicts-indep-build-conflicts-arch https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml [2] https://lists.debian.org/debian-devel/2024/05/msg00426.html -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
