[Pkg-sysvinit-devel] Supporting tmpfs on /var/run

[Henrique de Moraes Holschuh]

On Fri, 23 Dec 2005, Thomas Hood wrote:
> There is a certain elegance to a skeleton hierarchy: it looks just
> like what you want in the volatile hierarchy and you can maintain
> it (add directories and files, change permissions) using standard
> tools.  One can include things like README files.

I fail to see what difference /var/run with stuff created by initscripts
differ from this, they certainly use standard tools :-)

If you mean registering stuff with dpkg, I doubt shipping things elsewhere
in the deb (i.e. inside the skeleton) is any more useful than not shipping
them at all, except for colision avoidance (and we can do this through
policy anyway).

We can go with the skeleton stuff, but IMHO it is overkill for about 99% (if
not 100%) of the packages, and it looks to me like a waste of resources.  I
certainly would prefer not to switch over my packages using
dpkg-statoverride to a skeleton (but I would do it, if it is the consensus
we reach).

> The dpkg-statoverride approach looks as if it would work too.  Does
> this approach have advantages?

It works.  And I deployed it a long time ago in a bunch of packages, some of
them with a lot of users, and nobody even noticed it. So I'd say it works
_well_.

The catch is that dpkg-statoverrides are extremely hostile to people who do
extremely stupid things like deluser <*system* user of a package not
purged>.  dpkg/dpkg-statoverride won't forgive you an existing override to a
non-existent user (which might even be a dpkg bug, it should not abort
because of it, a warning is enough if the override won't be used at that
time).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh