On Sat, 14 May 2011, Roger Leigh wrote: > 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.
I wonder: If it's initscripts the package adding support for /run, why not just add /run in initscripts and wait until wheezy+1 before adding it to base-files? I feel that we are relying too much on base-files for no particular reason. In fact, I don't see any benefit of having /run in base-files at this point. > 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. Hmm, creating /var/lock as a symlink to /run/lock when /run is still empty is not going to be nice either, as it would be a dangling symlink. Again: Is it necessary or even useful to rely on base-files for this? How will this be handled on already running systems? Would be possible to do the same for not-yet-running systems? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
