Comment 8 for bug 1855140

> From my understanding this means that supporting an alternative init system is optional ("Packages may include support for alternate init systems besides systemd"). So basically this is up to the package maintainer whether or not the package should support an alternative init system.

I'm not sure that the Docker use case was intended to be within the scope of the Debian GR. But nevertheless, I think that in Debian it's still up to package maintainers to decide to what extent to support the Docker use case as it always has been. The Debian GR was relevant in that it didn't end up mandating an alternative to tmpfiles.d for example which might have affected any technical solution to this general problem.

For Ubuntu, I think it makes sense to support it and to send Debian package maintainers patches as appropriate.

The question is: how, technically, can we resolve this particular issue?

I think it would be best if it could be done centrally somehow, rather than tweaking each affected package individually. Could the systemd tmpfiles.d mechanism somehow be used by Docker image builds as a machine-readable list of temporary directories to arrange to be handled automatically? If so, then that one solution could fix this entire class of problem.