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

Reply via email to