[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var



On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > Another possible mitigation which I haven't previously seen proposed
> > is giving *elogind* a Depends or Recommends on systemd-*-standalone.
> > I think that would work to mitigate the failure mode with (1.) and (B.),
> > and the installed-size argument seems less interesting here because the
> > sort of systems that require elogind are already much larger anyway.
> > Would the elogind maintainers be willing to consider this? Does anyone
> > see a reason why it wouldn't work?
> 
> So to confirm, you think that if the elogind maintainers did this, then
> default-systemd-tmpfiles could point at systemd rather than
> systemd-standalone-tmpfiles, which the systemd maintainers prefer, but
> in addition, there aren't any scenarios in which people's systems are
> likely to be re-arranged when they don't want them to be?

Exactly. My hope is that if we had:

    Package: systemd
    Architecture: linux-any
    Provides: default-systemd-tmpfiles, systemd-tmpfiles
    Conflicts: systemd-tmpfiles
    Replaces: systemd-tmpfiles

    Package: systemd-standalone-tmpfiles
    Architecture: linux-any
    Provides: systemd-tmpfiles
    Conflicts: systemd-tmpfiles
    Replaces: systemd-tmpfiles

    Package: elogind
    Depends: systemd-standalone-tmpfiles        # or Recommends?

    Package: foo-service     # any package that requires tmpfiles.d(5)
    Depends: default-systemd-tmpfiles | systemd-tmpfiles

    # optionally, if someone does the work
    Package: openrc-tmpfiles                    # any other implementation
    Architecture: hurd-any kfreebsd-any
    Provides: default-systemd-tmpfiles, systemd-tmpfiles
    Conflicts: systemd-tmpfiles
    Replaces: systemd-tmpfiles

then the right thing (or at least *a* right thing) would happen in
all cases:

* install foo-service on a systemd-booted system:
  systemd is already installed and the dependency is satisfied

* install foo-service on a sysvinit-booted desktop system with elogind:
  elogind is already installed, therefore systemd-standalone-tmpfiles is
  already installed and the dependency is satisfied, avoiding #1016006 etc.

* install foo-service on a sysvinit-booted headless system with no elogind:
  systemd gets installed as a dependency by default, which is what the
  systemd maintainers would prefer to happen when there are no compelling
  space constraints; but the user can specifically ask for
  systemd-standalone-tmpfiles if that's what they'd prefer

* install foo-service in a container with no init system at all:
  systemd gets installed as a dependency by default, which is what the
  systemd maintainers would prefer to happen when there are no compelling
  space constraints; but the user can specifically ask for
  systemd-standalone-tmpfiles if that's what they'd prefer

* (optionally) install foo-service on hurd-i386:
  openrc-tmpfiles (or whatever) gets installed as a dependency

    smcv


Reply to: