On Wed, Apr 06, 2011 at 09:24:21AM +0200, Santiago Vila wrote: > Well, I added /run and this is what happened: > > http://bugs.debian.org/621036 > > Apparently, "it was stupid for base-files to ship /run without it > being useable", and the bug is reassigned to base-files. > > Does this mean I am supposed to setup /run as well? > That would be completely crazy! > > Please advise what to do. I am for removing /run from base-files > (because obviosuly nobody thought about a transition plan) and leaving > it entirely to initscripts or whatever package that will use /run.
Just FYI, initscripts has now entered unstable to introduce /run support. If you would like to re-introduce /run into base-files that would be great. There will be a window of potential breakage if base-files is upgraded prior to initscripts and initramfs-tools if the system is rebooted mid-way. At this point, /run will exist but will not be mounted by either initramfs-tools or initscripts. Rather than initscripts or initramfs-tools having a strict dependency on a new base-files or breaks on older versions (neither of which is true), I think the cleanest way would be if base-files could have a Breaks on initscripts (<< 2.88dsf-13.3), initramfs-tools (<< 0.99) which will ensure that they are upgraded first when doing a squeeze→wheezy upgrade. It would be nice if on new installs /var/run and /var/lock could be created as symlinks to /run and /run/lock. This will mean that debootstrapped chroots will have a valid setup here, since they will never be booted directly initscripts can't do this, and it's also too hairy for initscripts to do this to a chroot in its postinst. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
