On Fri, 15 Apr 2011, Roger Leigh wrote:
On Fri, Apr 15, 2011 at 01:38:34PM +0100, Edward Allcutt wrote: Your assumption is correct in that this is a fallback. This is the special case for chroots, also co-opted for vservers, which don't "boot" per se, and don't run the rcS scripts. The consequence of this is that we can't do any setup at boot time; the chances are that no filesystems will be mounted at all, and if there are, we don't have any control over that process. This means that the migration in postinst is unfortunately a "best effort"; I'd like to make it more reliable if at all possible.
In the case described, with a writable / and no tmpfs, what is the downside to my suggestion? /run would remain linked to /var/run forevermore[0] if the boottime switcheroo does not happen, but that doesn't seem so terrible. Both /run and /var/run will remain writable and effectively the same location, which points to the other isn't terribly important in the short term. [0] or until the admin prods it as specified in the release notes.
The assumption is that there won't be anything running having open files in /var/(run|lock)
I think that's an assumption that will fail in some cases and since we can avoid it we should do so. I have run things like databases and asterisk in chroots and would vastly prefer running upgrades to not be broken.
An alternative could be to just copy the contents, but we really do need the symlinks in place or else programs can't transition to the new paths transparently as on normal systems.
Copying the contents is the main thing I'm objecting to. I'm proposing creating symlinks which do allow a transparent transition and leaving it to the admin to switch the links around at a convenient time if rc scripts are skipped. I agree that unusual custom chroot environments can't always be handled fully automatically. Where I disagree is whether we should make assumptions which would break running systems rather than simply giving the admin the details needed to adapt the custom environment at a time convenient to them.[1] [1] I'm going to guess we'll assume they've taken care of such things before upgrading to wheezy+1. That seems like a much looser and safer assumption. Thank you very much for your time and effort on moving to /run in Debian. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1104151503390.30...@pandora.retrosnub.co.uk