Sean, On Tue, Jun 13, 2023 at 05:15:15PM +0100, Sean Whitton wrote: > > In principle and just looking at the dependencies this seems a viable > > solution. It is very similar to the way we handle the logind and > > default-logind virtual packages. > > Thank you for reviewing. Do you have a rough idea of how long it would > be until you could confirm that this is viable, and implement it in sid?
There is a new upstream version of elogind[1] that is already packaged in Devuan[2] although that uncovered up an upstream issue that I am waiting to be resolved[3]. So, maybe by the end of this month? However, that is only considering whether the packaging and dependencies can be made to work (like Simon McVittie, I think they probably can). I remain much less convinced that there is a consensus for requiring packages to use tmpfiles.d(5) for /var, /tmp and maybe /etc. The recent thread on debian-devel demonstrated a range of opinion. Thorsten and Bill have just raised valid points about chroots. So, whilst I am happy to test the dependency changes in elogind, enshrining this as a 'should' in the Policy now seems, at least, premature. Reading the proposed text as somebody who is particularly interested in non-systemd systems, I am struck by the inconsistency between Init systems other than ``systemd`` should allow providing the same functionality as appropriate for each system, for example managing the directories from the init script shipped by the package. and the fact that we no longer expect packages to include init scripts alongside their systemd units and even accept their removal, even if other interested people offer to maintain them and provide tested patches. With best wishes Mark [1] https://qa.debian.org/cgi-bin/watch?pkg=elogind [2] https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package&q=elogind=252.9-1~rc1 [3] https://github.com/elogind/elogind/issues/258
