On 2020-01-03 at 09:13, Ansgar wrote: > The Wanderer writes: > >> However, as it remains the case that they are shipped in the same >> package as /bin/systemd, and as I gather (mostly from this thread, >> I think) that some of the ways they are expected to be invoked >> probably rely on having systemd-the-daemon running > > They don't rely on the `/bin/systemd` binary at all, and I'm fairly > certain that this was mentioned in the thread (and previous) and not > the opposite. > > There was something about dh_installsystemd currently only running > systemd-tmpfiles in maintainer scripts if systemd run, but that can > be changed should Debian choose to use tmpfiles for more generic > purposes. It was Simon McVittie's message from half-past-noon (EST) yesterday, citing the various ways in which these facilities are invoked automatically on a systemd-as-PID1 system, that I was thinking of. Specifically, this part: >>> - run systemd-tmpfiles during boot (this is systemd-tmpfiles-setup.service, >>> part of systemd) >>> >>> - run systemd-sysusers during boot (this is >>> systemd-sysusers.service, part of systemd) Unless my understanding of the architecture of systemd-the-init-system is entirely incorrect, running these .service'es is handled by /bin/systemd. If having these programs run at boot time is considered essential to full functionality of these facilities - and I'd be surprised if it wasn't - then something is going to have to be done to permit that to happen under other init systems. That is, of course, equally true for any non-systemd implementations of these same facilities; as Simon also indicated, LSB init scripts or similar to invoke these facilities at boot time will be needed for opentmpfiles and opensysusers. If the maintainers of systemd-the-package would be willing to not only split out these binaries into standalone package(s), but accept such init scripts for inclusion in those packages, then I think that should entirely eliminate this particular concern; it should then be possible for other packages to depend on these facilities directly, without side effects for non-systemd environments. However, I don't see any particular reason to expect that to be the case, and certainly if it is not raised as a thing to be requested it is less likely to happen. Using opentmpfiles and opensysusers would make it possible to include those init scripts only in those packages, and avoid needing to have them on systemd-as-PID1 computers where they will never be used. That's not a major advantage, any more than avoiding .service files et cetera on computers without systemd is, but may not be of negligible weight either. >> this does not entirely obviate my concerns related to needing to >> have systemd-the-package's daemons present in order to gain access >> to these facilities. > > I'm happy to have helped overcome these concerns. Unfortunately, due to the above, the concerns remain. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature