Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Hi!
On Fri, 2019-11-29 at 09:13:47 -0800, Russ Allbery wrote:
> Guillem Jover <guillem@debian.org> writes:
> > As I mentioned on debian-devel, I think major parts of this and of the
> > sysuser stuff fall under dpkg realm. And my plan is to implement this
> > kind of functionality natively in dpkg, regardless of whatever the
> > outcome of that GR is.
>
> > Of course some parts of the functionality needed to manage/track
> > temporary pathnames requires integration or hooking into an init system
> > or chroot/container manager, but that's true regardless of the
> > implementation.
>
> Could you say more about how you think dpkg would be able to handle
> systemd-tmpfiles? As you mention, this is something that has to be done
> at every system boot, which seems pretty far afield from dpkg's domain.
> Do you want to maintain custom dpkg plugins for every init system that a
> dpkg system may support?
The way I see it, any pathname "owned" by a package is within the
realm of dpkg, which is in charge of tracking and managing the
filesystem contents for system software. I've, for example, always
found it a big defficiency that when querying dpkg about system
pathnames it cannot give a proper answer in many cases. The same with
verification of system pathnames. But this goes beyond temporary files,
this includes things like log or cache files, or other volatile
pathnames, for example.
These kinds of pathnames are also potential package cruft, that should
be cleaned up on package remove/purge (ideally in a configurable way,
as in “I want logs to be left behind after purge”), and w/o requiring
maintainer scripts.
<https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>
I don't mind much how this could end up being hooked into various init
systems and chroot/container managers. I can see how it could be done by
the respective imeplementations themselves or provided by dpkg itself,
I'm open to any of these TBH.
> (My recollection is that dpkg supports other OSes like Solaris.)
<https://wiki.debian.org/Teams/Dpkg/Porting>
<https://wiki.debian.org/Teams/Dpkg/Downstream>
> (systemd-sysusers is another matter and a bit more obviously doable with
> dpkg, although if Sam's option three wins, I'd ask everyone in the
> project, including you as dpkg maintainer, to consider the possible
> benefits of using cross-distribution mechanisms instead of Debian-specific
> mechanisms.)
<https://wiki.debian.org/Teams/Dpkg/Spec/SysUser>
To me that seems like an extremely unsatisfying and restrictive way
to characterize cross-distribution. This implies GNU/Linux-only ones,
not even things like musl-based, for example. I consider portability
of paramount importance, and I'll not stop caring about it, even if
the Debian project decided otherwise, less so as an upstream. (See my
GR amendment. :)
I find integration within Debian and with the wider dpkg ecosystem to
be way more interesting, and interfaces in dpkg that can work anywhere
where it would be available. That's why I'll work on this no matter
what, even if Debian decided to not use these features (which I'd find
rather unfortunate), I'd spend time on this at the expense of other
stuff.
Thanks,
Guillem
Reply to: