Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems
Michael, Thanks for this. On Mon, Jul 25, 2022 at 10:31:09AM +0200, Michael Biebl wrote: > My recommendation in [1] was that sysvinit-core should add a Depends on > systemd-standalone-tmpfiles (a Recommends would probably work fine as well). There is an obvious reason: sysvinit-core itself does not depend on any tempfiles implementation. Adding suprious dependencies to try to help APT find a particular solution seems misplaced logic to me and is against the Policy. Best wishes Mark
Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems
Simon, Thanks for this. On Mon, Jul 25, 2022 at 09:22:34AM +0100, Simon McVittie wrote: > Version 1.14.0-2 does not depend on systemd. It *does* depend > on either systemd or systemd-tmpfiles, as a result of having > /usr/lib/tmpfiles.d/dbus.conf (and will be one of increasingly many > packages that do this). > > systemd-tmpfiles is a virtual package representing any implementation > of the tmpfiles.d API. You can get this on a sysvinit/sysv-rc system by > installing the systemd-standalone-tmpfiles package. > sysvinit/sysv-rc is a non-default init system for Debian, and the init > system is a core component of the OS, so you can expect some upgrades > with a non-default init system to be non-trivial. Obviously the basic explanation here is perfrectly correct. However, as they stand, the dependencies being generated are causing users significant difficulty (judging by several bug reports in recent days with the same underlying cause) and APT does not readily find the correct solution. A suggestion to make the dependencies work better for everybody without manual intervention has already been made[1], but rejected. Respectfully, I suggest that is reconsidered. I see no downsides to making the dependency systemd-standalone-tmpfiles | systemd-tempfiles On systems where systemd is installed, the dependency will be already satisfied and therefore noop. On systems without systemd, apt install the standalone implementation. Are there any technical reasons why this is not a good technical solution? Thanks. Best wishes Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#15
Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems
On Mon, 25 Jul 2022 09:22:34 +0100 Simon McVittie wrote: > Version 1.14.0-2 does not depend on systemd. It *does* depend > on either systemd or systemd-tmpfiles, as a result of having > /usr/lib/tmpfiles.d/dbus.conf (and will be one of increasingly many > packages that do this). > > systemd-tmpfiles is a virtual package representing any implementation > of the tmpfiles.d API. You can get this on a sysvinit/sysv-rc system > by installing the systemd-standalone-tmpfiles package. Ok, thnx for the explanation. I overlooked the systemd-tmpfiles stanza: dep: systemd system and service manager or systemd-tmpfiles Package not available apt install systemd-standalone-tmpfiles resolves the issue. R. -- richard lucassen http://contact.xaq.nl/
Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems
Am 25.07.22 um 10:22 schrieb Simon McVittie: Control: retitle -1 dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems Control: severity -1 normal On Mon, 25 Jul 2022 at 09:38:50 +0200, Richard Lucassen wrote: Version 1.14.0-2 seems to depend on systemd which breaks my sys-V system and an update will remove many packages. Version 1.14.0-2 does not depend on systemd. It *does* depend on either systemd or systemd-tmpfiles, as a result of having /usr/lib/tmpfiles.d/dbus.conf (and will be one of increasingly many packages that do this). systemd-tmpfiles is a virtual package representing any implementation of the tmpfiles.d API. You can get this on a sysvinit/sysv-rc system by installing the systemd-standalone-tmpfiles package. sysvinit/sysv-rc is a non-default init system for Debian, and the init system is a core component of the OS, so you can expect some upgrades with a non-default init system to be non-trivial. There is no mention of a dependency change in the changelogs. This dependency is automatically generated by debhelper (since 13.8, see #1013969), so it is not a direct result of any change to dbus, and therefore there is no changelog entry. A simple rebuild of an older version of dbus with the new debhelper would have had the same effect. My recommendation in [1] was that sysvinit-core should add a Depends on systemd-standalone-tmpfiles (a Recommends would probably work fine as well). Unfortunately, this idea was dismissed with imho no proper justification. The sysvinit folks might even consider introducing a new meta package where they can introduce dependencies like this one. It's ultimately up to them. They just have to keep in mind that the tail is not going to wag the dog. Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#10 OpenPGP_signature Description: OpenPGP digital signature
Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems
Control: retitle -1 dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems Control: severity -1 normal On Mon, 25 Jul 2022 at 09:38:50 +0200, Richard Lucassen wrote: > Version 1.14.0-2 seems to depend on systemd which breaks my sys-V > system and an update will remove many packages. Version 1.14.0-2 does not depend on systemd. It *does* depend on either systemd or systemd-tmpfiles, as a result of having /usr/lib/tmpfiles.d/dbus.conf (and will be one of increasingly many packages that do this). systemd-tmpfiles is a virtual package representing any implementation of the tmpfiles.d API. You can get this on a sysvinit/sysv-rc system by installing the systemd-standalone-tmpfiles package. sysvinit/sysv-rc is a non-default init system for Debian, and the init system is a core component of the OS, so you can expect some upgrades with a non-default init system to be non-trivial. > There is no mention of a dependency change in the changelogs. This dependency is automatically generated by debhelper (since 13.8, see #1013969), so it is not a direct result of any change to dbus, and therefore there is no changelog entry. A simple rebuild of an older version of dbus with the new debhelper would have had the same effect. smcv
