- Intro -

For those who don't know, upstream Debian has moved to using /run instead of /var/run as the tmpfs mount point for runtime files that are not meant to persist across reboots.

See: https://wiki.debian.org/ReleaseGoals/RunDirectory

This happened back in Wheezy (which became Debian Stable over a year ago I believe), so for example on my Debian Wheezy system, things look like this:
(/run is the actual tmpfs mountpoint folder, and /var/run is a symlink to /run)

I think there are a couple of good reasons why we should strive to mimic upstream in this matter:
1. It's one less thing to worry about when packaging upstream software for our repos, or when trying to bring Fremantle as a whole closer to upstream.
2. In general, I personally think the overall decision to use a dedicated /run folder instead of /var/run is a good one.

Now, admittedly, in practice this doesn't matter too much. Most programs can be compile-time or run-time configured to use a different directory for their runtime files, and almost everything still uses /var/run instead of /run in most packages today. However, as a coder, I prefer to have as much standardization across systems as possible, and in order to not have everything constantly stuck in the past, in the long run that means I'd like to see older systems conform to newer approaches sooner rather than later. I think in the long run, we all benefit if systems do that.

- Proposal -

So, my suggestion is, we agree as a community on some sort of metapackage name which we can have other packages depend on, if those packages expect/want the /run directory, instead of /var/run.

I tentatively put forth "system-feature-root-run-dir". I used the various "kernel-feature-foo" virtual packages as examples for this.
I suggest "system-feature-" as the prefix because it's a general system-level thing, not really specific to a kernel or any particular package.
I suggest the "root-run-dir" part, because it's a fairly short but easily legible description of what it is: a "run" dir(ectory) at the root of the filesystem.

Then, various packages can provide various approaches to providing a /run folder, and each can add "system-feature-root-run-dir" (or whatever name we settle on) in their "Provides" field., like we do with the "kernel-feature-foo" metapackages.

For my part, I decided to quickly make a couple of very basic packages containing two different approaches towards creating this compatibility I'm talking about, and have thrown them in extras-devel. They've both passed the autobuilder and have been queued for moving into the extras-devel repos, so unless I made some sort of mistake that I don't realize, they should be hitting extras-devel in a few hours (or however long it takes our infra to do it).

- Approach 1 -

The most simple (albeit I'd say less proper) way to create compatibility with upstream packages (which might use /run instead of /var/run) is to just do:
That way, you have the inverse of the upstream: /var/run is still the mount point, but /run is a symlink to it, so for example if you're manually installing packages from Debian Wheezy or above (which I've done on occasion) you don't have to worry if they're configured/built/hardcoded to use /run instead of /var/run - it'll still work now.

So for the first approach I made a very primitive package, "root-run-dir-symlink", which will do something like this this, albeit with a bit more robustness:

Its preinst script will just ln -sf /var/run /run, and thats it. Its prerm script will remove /run (assuming it's still a symlink and said link is still pointing to a directory).

- Approach 2 -

A possibly race-condition-y approach that I've found safe enough in practice, but which might break in case some service is actually trying to use /var/run at the moment of doing the change, is to do something like this:

Once this is done, /run is your tmpfs mountpoint, and /var/run is a symlink to /run, preserving compatibility with programs using /var/run. The last line will ensure that the change doesn't get clobbered by reboots, because /etc/init.d/rcS is coded to check if /var/run is a symlink, and to recreate it as a directory if it is, for some reason... (I imagine because mounting stuff over a symlink can cause the whole mountpoint managing system to get confused if you remove the symlink itself (the kernel knows the thing is still mounted on the directory the symlink pointed to, but umount can't unmount it). Or something like that maybe?)

So this one has more downsides: It involves race-condition-y windows of time when /var/run is being migrated to /run, so certain files will either not be available in /var/run, or will be created only to be immediately lost (after the mv command is started and before /var/run is finally made into a symlink), and requires you to mess with a system file (/etc/init.d/rcS). But I figured some people might want to go this route anyway, so I figured I'd throw it up in extras-devel as well (though I still haven't decided if I'll bother promoting it).

So my second, still fairly primitive package is "root-run-dir", which will perform the above example steps (with a tiny handful of checks not in the example above) in preinst, and the reverse (same code, but swap /run and /var/run) in prerm.

- Approach 3 -

The truly safest way to do this, is to make sure this setup happens in early-enough boot that nothing is using /var/run yet. Then you can delete and symlink /var/run in peace. But scripting such a thing requires more intrusive changes to system files.

Now, on my personal N900s, a month or two ago, I just did this:
..then I reboot, and using my modifications to my /sbin/preinit, drop into an extremely-early-in-boot-process root shell, from which I do:
This ensures that once the boot completes, my system's /run and /var/run situation is in line with upstream stable Debian, and because I do the second part in extremely-early boot, I know nothing is actually seriously using /var/run (busybox's "watchdog" command, which I need for my early boot shell to not get killed by the watchdog stuff, puts a pid file in there, but there's no problem if that just gets clobbered when the above 'rm -r' runs.

However, obviously, this is by no means a user friendly mechanism.

I COULD script something that will either modify /etc/init.d/rcS, or /etc/event.d/rcS, and thereby insert a bunch of lines that would force the migration to happen in very early boot. Even better, one could change /etc/even.d/rcS to exec /etc/init.d/rcS-shim, rcS-shim could be a small script which does all the migration steps, changes /etc/event.d/rcS to exec /etc/init.d/rcS again as before, then finally deletes itself and execs into /etc/init.d/rcS. (That way the one-time migration code doesn't have to sit around on the system from then on.)

I even started making a script that would do this. But I decided the above two were 'good enough', especially since such a script would be very invasive (in terms of how it would have to mess with system files a lot more extensively than the prior two approaches).

What I would like to really see, is for the CSSU to do something like this. Since the CSSU is a system update, and is "in charge of" the system files that would have to be touched in order to cause such a smooth, during-next-boot migration, I would feel most comfortable in having the CSSU do such a thing.

However, if people want, I wouldn't mind making a .deb for this approach, and throwing that up into extras-devel, as well. And honestly, if those people are the CSSU people, and they want me to write something even more careful and robust to go into one of their updates, I would be happy to do so too. *Shrug*

- Summary -

Anyway, what I'd like, is to hear people's feedback on all of this. Some general directions for discussion:

1. Whether or not this is even a worthwhile thing to care about to start with. For example: "This whole thing is stupid, we don't even need compatibility with upstream's /run approach."
2. What people think about the proposed metapackage name "system-feature-root-run-dir".
3. What people think about the various approaches to actually providing a /run dir I provided as examples, especially any improvements people can think of as far as implementation of either of them goes.