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

[Luca Boccassi]

On Sun, 18 Sep 2022 20:52:23 -0700 Russ Allbery <rra at debian.org> wrote:
> Ansgar <ansgar at 43-1.org> writes:
> 
> > I would like to recommend packages to use tmpfiles.d(5) to manage
> > creating directories in locations such as /var or /etc instead of
> > maintainer scripts.
> 
> > It could also be used to create trivial files below /var that
should be
> > recreated if deleted by accident (such as atd's sequence number
which is
> > currently created by the maintainer script).
> 
> Hi all,
> 
> Here's where I think we currently are with this proposal:
> 
> * There should no longer be any blocker to adding a dependency on
>   systemd-tmpfiles since systemd-standalone-tmpfiles exists.
> 
> * So far as I can tell, dh_installtmpfiles adds the correct stanza to
the
>   postinst script for a service to run systemd-tmpfiles after the
package
>   has installed its tmpfiles.d fragment.  I believe that addresses
>   creating these files on installation on systems without any init
system?
>   (Obviously if tmpfs file systems are subsequently reset on such a
>   system, there is nothing in place to recreate these tmp files, but
I
>   think that's expected and not something we can address?)
> 
> * Guillem plans to add support to dpkg to register these files
properly as
>   package-associated files and also handle creation of the files. 
This is
>   great, and I am 100% in favor of it.  I don't think that blocks
this
>   change; to the contrary, I think this change is a good incremental
step
>   towards that world, since it moves temporary file creation out of
>   maintainer scripts into a declarative syntax.  dpkg can then either
>   consume the same syntax or packages can later convert that syntax
to
>   whatever dpkg uses, depending on how the dpkg implementation works,
>   which will be a simple and easy-to-detect migration that Lintian
can
>   diagnose.
> 
> Therefore, I don't see anything blocking adopting this as a policy
now,
> and it seems like an obviously good idea to me.
> 
> Am I missing something?  If not, I think the next step is for someone
to
> propose wording.

I've done an initial attempt to define the wording, although I'm sure
it will need quite a few changes. Attached as a patch, and also
available on Salsa:

https://salsa.debian.org/bluca/policy/-/commits/tmpfiles

Happy to move/reword/change/enhance as required.

> In order to handle installations that have no init system, I think we
may
> have to require that the dependency be listed as:
> 
>     systemd-standalone-tmpfiles | systemd-tmpfiles
> 
> to avoid trying to install systemd into an init-free chroot.  Maybe I
have
> that wrong?  Currently, dh_installtmpfiles doesn't add a dependency
at
> all, probably because it assumes that the package will use a fallback
to
> create the files in cases without an init system?  Either way, we
should
> address this in the Policy wording, and then encode that in
> dh_installtmpfiles if needed.

For now I've kept only a mention of the 'systemd-tmpfiles' virtual
package. As maintainers we would really prefer if the 'main'
implementation is pulled in whenever possible. When a minimal
installation is desired (ie, a minbase), it is possible to manually
specify the -standalone variant.

This was a controversial point last year, see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441

We could even decide that no dependency is added at all by dh, and
instead the build tool needs to decide if it's building an image where
tmpfiles snippets need to be ran, and if so pull in the preferred
alternative.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Define-tmpfiles.d-interface-and-usage.patch
Type: text/x-patch
Size: 37998 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230509/a2614eb3/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230509/a2614eb3/attachment-0001.sig>