Hello! This RC bug report has started appearing on my "Maintainer dashboard" ( https://udd.debian.org/dmd/ ) since my sysvinit NMU.
While at first look it seemed simple to get out of the way by just declaring a package relationship, on second thought it's not that easy... bootlogd conflicting with systemd-sysv isn't sufficient since people can boot with systemd even without having systemd-sysv installed. Also what would apt do if this relation is there and someone tries to install bootlogd? I guess apt might try to satisfy the relation by removing systemd-sysv and installing some other init system which seems like a horrible thing to do to users who aren't paying attention and blindly trusts apt (which many seems to do according to my experience with bug triaging and user interaction). Declaring a conflicts against systemd package would also not be right since it's quite likely people will have that package installed even when they're using another init system. (I've also asked systemd maintainers for advice on the above but they wanted to avoid getting involved in this and said it's up to bootlogd maintainers.) Also, it's still unknown /why/ bootlogd doesn't work with systemd! Apparently bootlogd relies on some facitily not provided by systemd. The relation should likely be described as a Depends against whatever provides the required facility, rather than a conflicts against systemd! Last but not least, this is from the bootlogd source: > * *NOTE* *NOTE* *NOTE* > * This is a PROOF OF CONCEPT IMPLEMENTATION http://sources.debian.net/src/sysvinit/2.88dsf-59.4/src/bootlogd.c/#L28 We should probably not ship something just because it compiles, specially not when it contains an explicit warning about its status. I'm thus leaning towards simply stop shipping the bootlogd package by disabling the Package: bootlogd part of sysvinit debian/control if solving this RC bug is left up to me. (There are no reverse dependencies of bootlogd package in stretch or sid.) Regards, Andreas Henriksson