Bug#620157: base-files: Please add top-level /run
Ok, I'm starting to understand the idea of making symlinks only in the initial install. Assuming that I manage to do the same in a different way, it would be ok for you, right? (In particular, I'm thinking about creating /var/run and /var/lock symlinks even if they are provided as directories inside the .deb. As far as they are never dropped, I think that would be cleaner than letting dpkg remove them and restoring afterwards). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
On Fri, May 27, 2011 at 10:49:52AM +0200, Santiago Vila wrote:
Ok, I'm starting to understand the idea of making symlinks only in the
initial install.
Assuming that I manage to do the same in a different way, it would be
ok for you, right?
Absolutely.
(In particular, I'm thinking about creating /var/run and /var/lock
symlinks even if they are provided as directories inside the .deb.
As far as they are never dropped, I think that would be cleaner than
letting dpkg remove them and restoring afterwards).
I was thinking about this while waking up this morning. I've attached
a patch to do this.
We retain /var/run and /var/lock as directories. This means all
upgrades will be reliable--there's no gap where they might not
exist. In the initial install we convert them to symlinks in
the postinst. I've created a shell function to do this, which
also takes care to move the contents (if any). At this point it's
extremely unlikely anything will be present (there isn't testing
with debootstrap), but it doesn't hurt.
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.
diff -urN base-files-6.3.original/debian/changelog base-files-6.4/debian/changelog
--- base-files-6.3.original/debian/changelog 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/changelog 2011-05-27 09:50:45.296957386 +0100
@@ -1,5 +1,25 @@
base-files (6.3) unstable; urgency=low
+ * Provide /run directory. Closes: #620157.
+ * For new installations:
+- /run/lock is created if not present (note that debian-installer
+ will remove it after installation is complete so that it does not
+ leave mess in /run; it will persist in chroot environments).
+ This ensures that the /var/lock symlink will always be valid.
+- /var/run is symlinked to /run.
+- /var/lock is symlinked to /run/lock.
+ * For upgrades, initscripts will handle the /var/run and /var/lock
+migration to /run.
+ * Break initscripts 2.88dsf-13.3 to ensure that once we provide
+/run, it is guaranteed to be present and functional. This is to
+prevent udev breakage by preventing base-files from being
+upgraded prior to initscripts on upgrade from squeeze. This
+ensures that initscripts must be upgraded first.
+
+ -- Roger Leigh rle...@debian.org Fri, 27 May 2011 09:45:39 +0100
+
+base-files (6.3) unstable; urgency=low
+
* Dropped /run until everything else is ready for it. In particular,
udev should not blindly assume that it works just because it exists.
diff -urN base-files-6.3.original/debian/control base-files-6.4/debian/control
--- base-files-6.3.original/debian/control 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/control 2011-05-26 15:16:37.342127868 +0100
@@ -11,6 +11,7 @@
Essential: yes
Priority: required
Replaces: base, miscutils, dpkg (= 1.15.0)
+Breaks: initscripts ( 2.88dsf-13.3)
Description: Debian base system miscellaneous files
This package contains the basic filesystem hierarchy of a Debian system, and
several important miscellaneous files, such as /etc/debian_version,
diff -urN base-files-6.3.original/debian/directory-list base-files-6.4/debian/directory-list
--- base-files-6.3.original/debian/directory-list 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/directory-list 2011-05-27 08:49:16.486529468 +0100
@@ -10,6 +10,7 @@
mnt
proc
root
+run
sbin
tmp
usr
diff -urN base-files-6.3.original/debian/postinst.in base-files-6.4/debian/postinst.in
--- base-files-6.3.original/debian/postinst.in 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/postinst.in 2011-05-27 09:49:59.124336034 +0100
@@ -23,6 +23,25 @@
fi
}
+migrate_directory() {
+ # Skip if already a symlink
+ if [ -L $1 ]; then
+:
+ else
+# Move any files to the new location
+if [ -d $1 ]; then
+ for file in $1/*; do
+ if [ -e $file ]; then
+ mv $file $2
+ fi
+ done
+ rmdir $1
+fi
+# Replace with symlink
+ln -s $2 $1
+ fi
+}
+
if [ ! -e /etc/dpkg/origins/default ]; then
if [ -e /etc/dpkg/origins/#VENDORFILE# ]; then
ln -sf #VENDORFILE# /etc/dpkg/origins/default
@@ -41,10 +60,17 @@
install_directory var/opt 755 root
install_directory media 755 root
install_directory var/mail 2775 mail
+ # Note that /run/lock will be later removed by debian-installer on
+ # completion of the install (a tmpfs will be mounted on /run at
+ # reboot). It will persist in debootstrapped chroots.
+ install_directory run/lock 1777 root
if [ ! -L /var/spool/mail ]; then
ln -s ../mail /var/spool/mail
fi
+ migrate_directory /var/run /run
+ migrate_directory /var/lock /run/lock
+
install_local_dir /usr/local
install_local_dir /usr/local/share
install_local_dir /usr/local/share/man
signature.asc
Bug#620157: base-files: Please add top-level /run
El 27/05/11 10:59, Roger Leigh escribió: On Fri, May 27, 2011 at 10:49:52AM +0200, Santiago Vila wrote: Ok, I'm starting to understand the idea of making symlinks only in the initial install. Assuming that I manage to do the same in a different way, it would be ok for you, right? Absolutely. (In particular, I'm thinking about creating /var/run and /var/lock symlinks even if they are provided as directories inside the .deb. As far as they are never dropped, I think that would be cleaner than letting dpkg remove them and restoring afterwards). I was thinking about this while waking up this morning. I've attached a patch to do this. We retain /var/run and /var/lock as directories. This means all upgrades will be reliable--there's no gap where they might not exist. In the initial install we convert them to symlinks in the postinst. I've created a shell function to do this, which also takes care to move the contents (if any). At this point it's extremely unlikely anything will be present (there isn't testing with debootstrap), but it doesn't hurt. No moving things, please. You told me this was for bootstrapping only, so I'll skip that part. If base-files is going to be officially in charge of creating those symlinks in the initial install, I hope that nobody else is fiddling with them (in the initial install). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
On Fri, May 27, 2011 at 11:10:14AM +0200, Santiago Vila wrote:
El 27/05/11 10:59, Roger Leigh escribió:
On Fri, May 27, 2011 at 10:49:52AM +0200, Santiago Vila wrote:
Ok, I'm starting to understand the idea of making symlinks only in the
initial install.
Assuming that I manage to do the same in a different way, it would be
ok for you, right?
Absolutely.
(In particular, I'm thinking about creating /var/run and /var/lock
symlinks even if they are provided as directories inside the .deb.
As far as they are never dropped, I think that would be cleaner than
letting dpkg remove them and restoring afterwards).
I was thinking about this while waking up this morning. I've attached
a patch to do this.
We retain /var/run and /var/lock as directories. This means all
upgrades will be reliable--there's no gap where they might not
exist. In the initial install we convert them to symlinks in
the postinst. I've created a shell function to do this, which
also takes care to move the contents (if any). At this point it's
extremely unlikely anything will be present (there isn't testing
with debootstrap), but it doesn't hurt.
No moving things, please. You told me this was for bootstrapping
only, so I'll skip that part.
If base-files is going to be officially in charge of creating those
symlinks in the initial install, I hope that nobody else is fiddling
with them (in the initial install).
This is to cater for the case that
- base files in unpacked (/var/run created)
- another package puts something in /var/run in its postinst
e.g. service start
- base files is configured (/var/run is not removable due to
files being present).
That said, the chance of this happening during debootstrap is very
low (zero at this point in time). No package currently does this,
so a simple
migrate_directory() {
if [ ! -L $1 ]; then
rmdir $1
ln -s $2 $1
fi
}
is quite sufficient.
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
Bug#620157: base-files: Please add top-level /run
On Fri, May 27, 2011 at 11:10:14AM +0200, Santiago Vila wrote:
El 27/05/11 10:59, Roger Leigh escribió:
On Fri, May 27, 2011 at 10:49:52AM +0200, Santiago Vila wrote:
(In particular, I'm thinking about creating /var/run and /var/lock
symlinks even if they are provided as directories inside the .deb.
As far as they are never dropped, I think that would be cleaner than
letting dpkg remove them and restoring afterwards).
I was thinking about this while waking up this morning. I've attached
a patch to do this.
We retain /var/run and /var/lock as directories. This means all
upgrades will be reliable--there's no gap where they might not
exist. In the initial install we convert them to symlinks in
the postinst. I've created a shell function to do this, which
also takes care to move the contents (if any). At this point it's
extremely unlikely anything will be present (there isn't testing
with debootstrap), but it doesn't hurt.
No moving things, please. You told me this was for bootstrapping
only, so I'll skip that part.
If base-files is going to be officially in charge of creating those
symlinks in the initial install, I hope that nobody else is fiddling
with them (in the initial install).
Patch attached with the moving removed. Tested with debootstrap.
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.
diff -urN base-files-6.3.original/debian/changelog base-files-6.4/debian/changelog
--- base-files-6.3.original/debian/changelog 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/changelog 2011-05-27 10:29:51.094294861 +0100
@@ -1,3 +1,23 @@
+base-files (6.4) unstable; urgency=low
+
+ * Provide /run directory. Closes: #620157.
+ * For new installations:
+- /run/lock is created if not present (note that debian-installer
+ will remove it after installation is complete so that it does not
+ leave mess in /run; it will persist in chroot environments).
+ This ensures that the /var/lock symlink will always be valid.
+- /var/run is symlinked to /run.
+- /var/lock is symlinked to /run/lock.
+ * For upgrades, initscripts will handle the /var/run and /var/lock
+migration to /run.
+ * Break initscripts 2.88dsf-13.3 to ensure that once we provide
+/run, it is guaranteed to be present and functional. This is to
+prevent udev breakage by preventing base-files from being
+upgraded prior to initscripts on upgrade from squeeze. This
+ensures that initscripts must be upgraded first.
+
+ -- Roger Leigh rle...@debian.org Fri, 27 May 2011 09:45:39 +0100
+
base-files (6.3) unstable; urgency=low
* Dropped /run until everything else is ready for it. In particular,
diff -urN base-files-6.3.original/debian/control base-files-6.4/debian/control
--- base-files-6.3.original/debian/control 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/control 2011-05-26 15:16:37.342127868 +0100
@@ -11,6 +11,7 @@
Essential: yes
Priority: required
Replaces: base, miscutils, dpkg (= 1.15.0)
+Breaks: initscripts ( 2.88dsf-13.3)
Description: Debian base system miscellaneous files
This package contains the basic filesystem hierarchy of a Debian system, and
several important miscellaneous files, such as /etc/debian_version,
diff -urN base-files-6.3.original/debian/directory-list base-files-6.4/debian/directory-list
--- base-files-6.3.original/debian/directory-list 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/directory-list 2011-05-27 08:49:16.486529468 +0100
@@ -10,6 +10,7 @@
mnt
proc
root
+run
sbin
tmp
usr
diff -urN base-files-6.3.original/debian/postinst.in base-files-6.4/debian/postinst.in
--- base-files-6.3.original/debian/postinst.in 2011-05-25 18:46:08.276544484 +0100
+++ base-files-6.4/debian/postinst.in 2011-05-27 10:30:18.894631742 +0100
@@ -23,6 +23,13 @@
fi
}
+migrate_directory() {
+ if [ ! -L $1 ]; then
+rmdir $1
+ln -s $2 $1
+ fi
+}
+
if [ ! -e /etc/dpkg/origins/default ]; then
if [ -e /etc/dpkg/origins/#VENDORFILE# ]; then
ln -sf #VENDORFILE# /etc/dpkg/origins/default
@@ -41,10 +48,17 @@
install_directory var/opt 755 root
install_directory media 755 root
install_directory var/mail 2775 mail
+ # Note that /run/lock will be later removed by debian-installer on
+ # completion of the install (a tmpfs will be mounted on /run at
+ # reboot). It will persist in debootstrapped chroots.
+ install_directory run/lock 1777 root
if [ ! -L /var/spool/mail ]; then
ln -s ../mail /var/spool/mail
fi
+ migrate_directory /var/run /run
+ migrate_directory /var/lock /run/lock
+
install_local_dir /usr/local
install_local_dir /usr/local/share
install_local_dir /usr/local/share/man
signature.asc
Description: Digital signature
Bug#620157: base-files: Please add top-level /run
On Mon, May 23, 2011 at 01:52:05PM +0100, Roger Leigh wrote: There are four possible upgrade/install paths to consider: 1) squeeze→wheezy upgrade (normal system) 2) squeeze→wheezy upgrade (chroot) 3) clean wheezy install (normal system) 4) clean wheezy install (chroot) With /run being provided by initscripts, we handle (1) and (3) just fine. Initially /run is absent, created on initscripts install, and migration completed after reboot. With (2) we do a best effort with symlinks, but don't do a very good job: /run is a symlink to /var/run, so the old directories remain in place (we can't safely move them). For (4) we really want the new directory structure with compatibility symlinks, rather than a repeat of (2), or else chroots, even freshly debootstrapped ones, will never be able to migrate to the new hierarchy automatically. If this was already set up by base-files, we wouldn't have a problem, but it's not, so debootstrapping a current unstable chroot results in the upgrade cludge we use for (2). 3) wheezy install (normal system) base-files provides /run base-files does not provide /var/run, /var/run does not exist base-files creates /var/run symlink to /run initscripts provides /run [* no tmpfs mounted on /run at this point] initscripts sees /var/run already symlinked, so no action [/var/run→/run] [reboot] tmpfs mounted on /run initscripts sees /var/run already symlinked, so no action [/var/run→/run] 4) wheezy install (chroot) base-files provides /run base-files does not provide /var/run, /var/run does not exist base-files creates /var/run symlink to /run initscripts also provides /run initscripts sees /var/run already symlinked, so no action [/var/run→/run] Hi, The attached patch corrects the known deficiencies above. The debian-installer team have also added in support for /run to ensure that debootstrap works correctly for chroot environments and real installs. The patch makes the package provide /run (it contains a Breaks: on older initscripts to avoid a repeat of the udev breakage, without introducing an initscripts dependency, so this works for both upgrades and fresh installs). We create /run/lock in the postinst if absent, and then /var/run and /var/lock as symlinks. Unlike previous patches, because we always create /run/lock when we create the /var/lock symlink, it's always valid, so this is no longer able to cause breakage. So base-files always installs a working setup on initial install (it leaves upgrades to initscripts or systemd). The change is now in debian-installer, which purges the contents of /run after install so cruft isn't left behind which would be obscured by the tmpfs mount on /run after reboot. So in summary, this should be safe to apply - we cope with /run being added by the Breaks - otherwise we only make changes on new installs, and we ensure that we always provide valid symlinks. 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. diff -urN ../base-files-6.3.original/debian/1777-dirs ./debian/1777-dirs --- ../base-files-6.3.original/debian/1777-dirs 2011-05-25 18:46:08.276544484 +0100 +++ ./debian/1777-dirs 2011-05-25 19:37:07.471912770 +0100 @@ -1,3 +1,2 @@ tmp -var/lock var/tmp diff -urN ../base-files-6.3.original/debian/changelog ./debian/changelog --- ../base-files-6.3.original/debian/changelog 2011-05-25 18:46:08.276544484 +0100 +++ ./debian/changelog 2011-05-26 15:25:05.676769129 +0100 @@ -1,3 +1,24 @@ +base-files (6.4) unstable; urgency=low + + * Provide /run directory. Closes: #620157. + * Do not provide /var/run or /var/lock directories. + * For new installations: +- /run/lock is created if not present (note that debian-installer + will remove it after installation is complete so that it does not + leave mess in /run; it will persist in chroot environments). + This ensures that the /var/lock symlink will always be valid. +- /var/run is symlinked to /run. +- /var/lock is symlinked to /run/lock. + * For upgrades, initscripts will handle the /var/run and /var/lock +migration to /run. + * Break initscripts 2.88dsf-13.3 to ensure that once we provide +/run, it is guaranteed to be present and functional. This is to +prevent udev breakage by preventing base-files from being +upgraded prior to initscripts on upgrade from squeeze. This +ensures that initscripts must be upgraded first. + + -- Roger Leigh rle...@debian.org Thu, 26 May 2011 15:16:46 +0100 + base-files (6.3) unstable; urgency=low * Dropped /run until everything else is ready for it. In particular, diff -urN ../base-files-6.3.original/debian/control ./debian/control --- ../base-files-6.3.original/debian/control
Bug#620157: base-files: Please add top-level /run
[ Note: Thanks a lot for the patch and sorry for not answering before ]. El 26/05/11 16:37, Roger Leigh escribió: @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp So, you propose that base-files des not contain var/lock or var/run anymore. I think that will not work: If we make var/run and var/lock to be symlinks, and then we upgrade base-files to a version which does not contain var/lock and var/run anymore, the symlinks will disappear, as dpkg will remove them. So, if the symlinks are useful at all, it will not be because base-files creates them, but instead because some other package creates them (which I think it is already the case), in which case we don't really need base-files to deal with them. This is why I think the best thing base-files can do for the good of the whole system is exactly to do nothing about this, which includes not removing var/lock and var/run if/when they are converted to symlinks by another package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
On Thu, May 26, 2011 at 08:04:50PM +0200, Santiago Vila wrote: [ Note: Thanks a lot for the patch and sorry for not answering before ]. El 26/05/11 16:37, Roger Leigh escribió: @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp So, you propose that base-files des not contain var/lock or var/run anymore. I think that will not work: If we make var/run and var/lock to be symlinks, and then we upgrade base-files to a version which does not contain var/lock and var/run anymore, the symlinks will disappear, as dpkg will remove them. To work around that, we can move the symlink creation out of the part of the postinst with the version check to do it unconditionally, so if the directories do not exist (for any reason--either initial bootstrap or loss on upgrade) we will create a symlink. So, if the symlinks are useful at all, it will not be because base-files creates them, but instead because some other package creates them (which I think it is already the case), in which case we don't really need base-files to deal with them. This is why I think the best thing base-files can do for the good of the whole system is exactly to do nothing about this, which includes not removing var/lock and var/run if/when they are converted to symlinks by another package. They key problem with this approach is that we can not bootstrap a system with a functional /run hierarchy unless it's done in base-files. The operative word here is *bootstrap*; upgrades are handled by initscripts, and initscripts can handle the transition fine in the context of a *running* system. But it can't handle it if it's not a live system (no init scripts run, and what's mounted is ill-defined). In the context of a chroot, and this includes both bootstrapping with debootstrap to create a basic chroot, or as part of debian-installer, we can't do the transition as I explained in the previous detailed email. Because we don't run init scripts, and can't reliably move directories, it needs creating at debootstrap time or else we can't migrate at all. Once /var/run and /var/lock exist as directories, it's too late--we can't alter them. This means that you won't be able to have /run in a wheezy or sid chroot (or fresh install) unless this change is made in base-files. It will remain a symlink to /var/run indefinitely, and this brings its own problems--it's different to a real system, and it will require special case handling. But the most important issue is that there is *no* upgrade path for these chroots--it's fixed from debootstrap time onwards. For a debootstrap in debian-installer, it will *not* be rectified by initscripts since it also won't migrate in a chroot environment, and this will result in /run being created as a symlink. It won't be rectified at boot time either, because /run and /var/run will point to the same place, so it won't alter it, and so new installs will be broken indefinitely. It will *eventually* happen: when initscripts' postinst runs once the system is rebooted, and then rebooted again after, but that might not be until wheezy+1 for stable installs, and it needs to be in place at install time. Colin Watson made the changes to debian-installer this morning to allow this to all work correctly for fresh installs. 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
Bug#620157: base-files: Please add top-level /run
On Thu, May 26, 2011 at 08:16:20PM +0100, Roger Leigh wrote: On Thu, May 26, 2011 at 08:04:50PM +0200, Santiago Vila wrote: [ Note: Thanks a lot for the patch and sorry for not answering before ]. El 26/05/11 16:37, Roger Leigh escribió: @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp So, you propose that base-files des not contain var/lock or var/run anymore. I think that will not work: If we make var/run and var/lock to be symlinks, and then we upgrade base-files to a version which does not contain var/lock and var/run anymore, the symlinks will disappear, as dpkg will remove them. To work around that, we can move the symlink creation out of the part of the postinst with the version check to do it unconditionally, so if the directories do not exist (for any reason--either initial bootstrap or loss on upgrade) we will create a symlink. Patch attached to do this (create symlinks if missing). Note that on new installs, the symlinks will always be created. This scenario only exists on upgrade, and due to the Breaks on initscripts this implies that on upgrade it will also always be a symlink as well. If it does get removed, it will be recreated in the 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. diff -urN base-files-6.3.original/debian/1777-dirs base-files-6.3/debian/1777-dirs --- base-files-6.3.original/debian/1777-dirs 2011-05-25 18:46:08.276544484 +0100 +++ base-files-6.3/debian/1777-dirs 2011-05-25 19:37:07.471912770 +0100 @@ -1,3 +1,2 @@ tmp -var/lock var/tmp diff -urN base-files-6.3.original/debian/changelog base-files-6.3/debian/changelog --- base-files-6.3.original/debian/changelog 2011-05-25 18:46:08.276544484 +0100 +++ base-files-6.3/debian/changelog 2011-05-26 15:25:05.676769129 +0100 @@ -1,3 +1,24 @@ +base-files (6.4) unstable; urgency=low + + * Provide /run directory. Closes: #620157. + * Do not provide /var/run or /var/lock directories. + * For new installations: +- /run/lock is created if not present (note that debian-installer + will remove it after installation is complete so that it does not + leave mess in /run; it will persist in chroot environments). + This ensures that the /var/lock symlink will always be valid. +- /var/run is symlinked to /run. +- /var/lock is symlinked to /run/lock. + * For upgrades, initscripts will handle the /var/run and /var/lock +migration to /run. + * Break initscripts 2.88dsf-13.3 to ensure that once we provide +/run, it is guaranteed to be present and functional. This is to +prevent udev breakage by preventing base-files from being +upgraded prior to initscripts on upgrade from squeeze. This +ensures that initscripts must be upgraded first. + + -- Roger Leigh rle...@debian.org Thu, 26 May 2011 15:16:46 +0100 + base-files (6.3) unstable; urgency=low * Dropped /run until everything else is ready for it. In particular, diff -urN base-files-6.3.original/debian/control base-files-6.3/debian/control --- base-files-6.3.original/debian/control 2011-05-25 18:46:08.276544484 +0100 +++ base-files-6.3/debian/control 2011-05-26 15:16:37.342127868 +0100 @@ -11,6 +11,7 @@ Essential: yes Priority: required Replaces: base, miscutils, dpkg (= 1.15.0) +Breaks: initscripts ( 2.88dsf-13.3) Description: Debian base system miscellaneous files This package contains the basic filesystem hierarchy of a Debian system, and several important miscellaneous files, such as /etc/debian_version, diff -urN base-files-6.3.original/debian/directory-list base-files-6.3/debian/directory-list --- base-files-6.3.original/debian/directory-list 2011-05-25 18:46:08.276544484 +0100 +++ base-files-6.3/debian/directory-list 2011-05-25 18:47:49.797635835 +0100 @@ -10,6 +10,7 @@ mnt proc root +run sbin tmp usr @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp diff -urN base-files-6.3.original/debian/postinst.in base-files-6.3/debian/postinst.in --- base-files-6.3.original/debian/postinst.in 2011-05-25 18:46:08.276544484 +0100 +++ base-files-6.3/debian/postinst.in 2011-05-26 20:45:30.520624985 +0100 @@ -41,9 +41,19 @@ install_directory var/opt 755 root install_directory media 755 root install_directory var/mail 2775 mail + # Note that /run/lock will be later removed by debian-installer on + # completion of the install (a tmpfs will be mounted on /run at + # reboot). It will persist in debootstrapped chroots. + install_directory run/lock 1777 root if [ ! -L /var/spool/mail ]; then ln -s ../mail /var/spool/mail fi + if [ ! -e /var/run ]; then +ln -s /run /var/run + fi + if [ ! -e /var/lock ]; then +ln -s
Bug#620157: base-files: Please add top-level /run
On Wed, May 18, 2011 at 01:57:04PM +0200, Santiago Vila wrote: 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. The main need for this is debootstrap. There's two possible ways initscripts can handle the migration: 1) Normal system - on installation, bind mount /var/run to /run, /var/lock to /run/lock - on reboot, set up /run as a tmpfs and convert the original locations to symlinks 2) Chroot or other virtual environment - the above isn't possible (no scripts run on startup etc.) - on installation, symlink /run → /var/run and /run/lock (/var/run/lock) → /var/lock You seem to imply that we should migrate each and every file at once. We could just declare /var/run obsolete and not make any bind mount or symlink. The use of /var/run then would just fade away over time, like it happened with the /usr/doc transition. The issue here is that /var/run is still an FHS-mandated directory, and while /run supersedes it, both need to be present and hold the same contents to allow migration. We could do it without the bind mount and symlinks, but then every package needs to manage migration from /var/run to /run including moving the pidfiles and other data. With the bind mount/symlink, this part is completely transparent: programs simply switch to the new path after wheezy is released, and that's it, so this saves a lot of effort for individual maintainers, unlike /usr/doc, which required every package to migrate separately (and this was files provided in packages, whereas /var/run is only dynamically created state, which simplifies things as well). The other issue I have is that the /usr/doc transition took *years*, and multiple stable releases to finalise. With this transition, we've taken a lot of effort to ensure that the transition is seamless, and immediate, to ease migration and allow for a much faster and simpler transition than /usr/doc. AFAIK (please correct me if I'm wrong), this is not like /var/mail where email clients look at a single place. Packages putting things in /var/run will look for them in /var/run, and packages putting things in /run will look for them in /run. Yes, this is the case. But with the existing migration, the contents at both locations are identical. But even if we want symlinks or bind mounts: I made a mistake in base-files 2.1.18 when I added /dev/pts (this was more than 10 years ago, but there are a lot of similarities). Things became too tricky because /dev was a virtual filesystem. I had to remove it in 2.1.20 with urgency=high, but since then it is clear to me that this kind of things are better handled by whatever package is actually populating those directories. I think I've perhaps explained why base-files needs to provide /run poorly, so I'll try better. It's fine for this to be done in initscripts for normal systems, but in chroots it's not so good. There are four possible upgrade/install paths to consider: 1) squeeze→wheezy upgrade (normal system) 2) squeeze→wheezy upgrade (chroot) 3) clean wheezy install (normal system) 4) clean wheezy install (chroot) With /run being provided by initscripts, we handle (1) and (3) just fine. Initially /run is absent, created on initscripts install, and migration completed after reboot. With (2) we do a best effort with symlinks, but don't do a very good job: /run is a symlink to /var/run, so the old directories remain in place (we can't safely move them). For (4) we really want the new directory structure with compatibility symlinks, rather than a repeat of (2), or else chroots, even freshly debootstrapped ones, will never be able to migrate to the new hierarchy automatically. If this was already set up by base-files, we wouldn't have a problem, but it's not, so debootstrapping a current unstable chroot results in the upgrade cludge we use for (2). These are the specific upgrade/install paths, with and without /run being provided by base-files. Note I'm only considering /var/run (/var/lock is treated identically, so I'm omitting it). In square brackets, I've put the state of /run and /var/run at that point (→ is a symlink, = is a bind mount). A) without base-files providing /run directory and /var/run symlink to /run: 1) squeeze→wheezy (normal system) initscripts adds /run initscripts bind mounts /var/run on /run [/var/run=/run] [reboot] initscripts mounts tmpfs on /run initscripts symlinks /var/run symlinked to /run [/var/run→/run] 2) squeeze→wheezy (chroot) initscripts adds /run initscripts removes /run and replaces it with a symlink to /var/run [/run→/var/run] 3) wheezy install (normal system) initscripts adds /run initscripts bind mounts /var/run on /run [/var/run=/run] [reboot] initscripts mounts tmpfs on /run initscripts symlinks
Bug#620157: base-files: Please add top-level /run
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. The main need for this is debootstrap. There's two possible ways initscripts can handle the migration: 1) Normal system - on installation, bind mount /var/run to /run, /var/lock to /run/lock - on reboot, set up /run as a tmpfs and convert the original locations to symlinks 2) Chroot or other virtual environment - the above isn't possible (no scripts run on startup etc.) - on installation, symlink /run → /var/run and /run/lock (/var/run/lock) → /var/lock You seem to imply that we should migrate each and every file at once. We could just declare /var/run obsolete and not make any bind mount or symlink. The use of /var/run then would just fade away over time, like it happened with the /usr/doc transition. AFAIK (please correct me if I'm wrong), this is not like /var/mail where email clients look at a single place. Packages putting things in /var/run will look for them in /var/run, and packages putting things in /run will look for them in /run. But even if we want symlinks or bind mounts: I made a mistake in base-files 2.1.18 when I added /dev/pts (this was more than 10 years ago, but there are a lot of similarities). Things became too tricky because /dev was a virtual filesystem. I had to remove it in 2.1.20 with urgency=high, but since then it is clear to me that this kind of things are better handled by whatever package is actually populating those directories. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
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
Bug#620157: base-files: Please add top-level /run
On Tue, May 17, 2011 at 05:37:18PM +0200, Santiago Vila wrote: 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. The main need for this is debootstrap. There's two possible ways initscripts can handle the migration: 1) Normal system - on installation, bind mount /var/run to /run, /var/lock to /run/lock - on reboot, set up /run as a tmpfs and convert the original locations to symlinks 2) Chroot or other virtual environment - the above isn't possible (no scripts run on startup etc.) - on installation, symlink /run → /var/run and /run/lock (/var/run/lock) → /var/lock (2) is only desirable on upgrade of a chroot due to issues moving files and directories. For a clean debootstrap, we want the proper hierarchy. 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. Maybe base-files could also provide /run/(lock|shm)? On a normal system, these will be hidden by the /run tmpfs, but will be used (potentially) in a chroot environment. This would ensure that the links are always valid. 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? If it's not done in base-files, I'm not sure where would be best to do this. initscripts is handling the migration of existing installations, and it does a perfectly good job for normal systems; however, chroot environments can't be catered for as well as I'd like. While we do a best-effort faking of the /run hierarchy using the existing /var directories and some symlinks, this isn't what we want for new installs. Unfortunately, by the time debootstrap configures initscripts, base-files already created /var/(run|lock) and we can't reliably replace them with symlinks at that point. In consequence, I would suggest that base-files could provide: /run /run/lock /run/shm /var/run → /run [symlink] /var/lock → /run/lock [symlink] The symlinks could be created in the postinst if they don't already exist (the directories would cease to be provided by the package directly). 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
Bug#620157: base-files: Please add top-level /run
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
Bug#620157: base-files: Please add top-level /run
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
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? Not at all. base-files was only intended to create /run as an empty directory. 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. We /have/ thought through a transition plan. It's been discussed on debian-devel and #debian-devel over the last week. The plan is that initscripts will set up a working /run (tmpfs) on boot and on package upgrade. Packages wanting to transition to use /run will have a versioned depends upon /run, which will ensure that it is both present *and* functional. udev decided to start using /run before this was completed, and without a versioned dependency. I have filed a bug against udev about this (#620995). IMO the best action for base-files is to do nothing. This is a bug in udev, and udev will need to be fixed to do the transition properly like all the other packages which will be transitioning to /run. I am planning on writing a detailed plan for the transition to debian-devel-announce detailing how this will work, but udev jumped the gun and started using it before we had got all the uploads done. 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
Bug#620157: base-files: Please add top-level /run
Ok, now that the patch has stabilized, some questions: * If I add /run to base-files, what would prevent anyone from submitting a bug report against base-files saying this is a FHS/policy violation? If we are going to make an exception to the FHS, could you please amend policy accordingly? (cloning this report and reassigning the clone to debian-policy would be a good start). * Do you really need a dependency on base-files? It seems to me that a simple mkdir /run in whatever package needs it would probably be enough to start using it. Of course I will gladly add /run to base-files for completeness, it's just that I don't see the need to have a dependency here. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620157: base-files: Please add top-level /run
On Mon, Apr 04, 2011 at 11:35:03AM +0200, Santiago Vila wrote: Hi Santiago, * If I add /run to base-files, what would prevent anyone from submitting a bug report against base-files saying this is a FHS/policy violation? This isn't strictly an FHS violation, from what I understand and have seen comments on WRT /run. The FHS defines a minimum set of directories, not a maximum, and distributions are free to add additional directories at their discretion. Additionally, /run isn't a Debian-specific feature; it is being implemented by Fedora (hence RHEL in time) and SuSE right now, and other distributions will be catching up in time. /run has been proposed for FHS inclusion, so it should become an official part of the FHS in time, especially since it will be implemented by all the major distributions. WRT being in violation of Policy, Policy documents existing best practice, so I don't think it can really go into Policy until we have a working implementation. OTOH, we have a working implementation done now, which should be deployed soon, so I think proposing a Policy change to add /run would be inappropriate. If we are going to make an exception to the FHS, could you please amend policy accordingly? (cloning this report and reassigning the clone to debian-policy would be a good start). I'll make a patch documenting the exception for /run in Policy, and make that bug blocked by this one, if that's OK? * Do you really need a dependency on base-files? It seems to me that a simple mkdir /run in whatever package needs it would probably be enough to start using it. Of course I will gladly add /run to base-files for completeness, it's just that I don't see the need to have a dependency here. We can certainly just provide /run in initscripts. It's just that it will be needed by other init systems (e.g. systemd, upstart), and that it's a replacement location for existing directories provided by base-files. If you think it's better for initscripts not to have a versioned base-files dependency and to just provide /run as well, I can certainly do that--I wasn't sure if that was appropriate given that it was a top-level directory which the system might be expected to provide. Regardless of how this is handled in the specific case of initscripts, I think it would be appropriate for base-files to provide /run. Kind 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
Bug#620157: base-files: Please add top-level /run
On Mon, Apr 04, 2011 at 01:50:47PM +0100, Roger Leigh wrote: If we are going to make an exception to the FHS, could you please amend policy accordingly? (cloning this report and reassigning the clone to debian-policy would be a good start). I'll make a patch documenting the exception for /run in Policy, and make that bug blocked by this one, if that's OK? Bug #620870 is a patch adding /run as an FHS exception to Policy. It references this bug. 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
Bug#620157: base-files: Please add top-level /run
On Fri, Apr 01, 2011 at 04:27:01PM +0100, Roger Leigh wrote: On Fri, Apr 01, 2011 at 10:40:52AM +0100, Roger Leigh wrote: On Wed, Mar 30, 2011 at 04:43:59PM +0100, Roger Leigh wrote: Attached is a patch for adding a new top-level directory, /run. References: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 https://lwn.net/Articles/436012/ This has already been adopted by Fedora, and it's something we've wanted in Debian for years (but settled on /lib/init/rw for FHS compliance). /run is wider in scope than /lib/init.rw, and will be used for transient writable data present from system startup to shutdown, which is not preserved across reboots, and will therefore supercede /var/run, /var/lock, /lib/init/rw and existing use of /dev and /etc as a place to put writable program state. Once set up by initscripts, I expect we will then need to replace /var/run and /var/lock with symlinks, which will require an additional change to base-files once /run is set up and functional. Bind mounting is an alternative, but bind mounting /run will hide files created earlier in the boot sequence, though it would be feasible for /var/lock. Updated patch attached. This allows the safe migration of /var/run and /var/lock by 1) dropping base-files ownership 2) ensuring their continued existence after dropping ownership This will permit initscripts/systemd to switch them to symlink or bind mount them at their discretion. We identified an issue with this patch in that /var/lock could be lost due to being empty and then not recreated. It turns out that this part of the patch is not needed at all, since dpkg is already perfectly capable of handling directories being symlinks, so the much simpler patch (attached) may be used instead, which simple creates /run only, and does nothing else. 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. diff -urN base-files-6.1.original/debian/changelog base-files-6.1/debian/changelog --- base-files-6.1.original/debian/changelog 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/changelog 2011-04-02 15:45:34.678407227 +0100 @@ -1,3 +1,9 @@ +base-files (6.1run0) unstable; urgency=low + + * Add /run. + + -- Roger Leigh rle...@debian.org Fri, 01 Apr 2011 09:26:35 +0100 + base-files (6.1) unstable; urgency=medium * Changed issue, issue.net and debian_version to read wheezy/sid. diff -urN base-files-6.1.original/debian/directory-list base-files-6.1/debian/directory-list --- base-files-6.1.original/debian/directory-list 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/directory-list 2011-04-02 15:39:40.784019553 +0100 @@ -10,6 +10,7 @@ mnt proc root +run sbin tmp usr signature.asc Description: Digital signature
Bug#620157: base-files: Please add top-level /run
On Wed, Mar 30, 2011 at 04:43:59PM +0100, Roger Leigh wrote: Attached is a patch for adding a new top-level directory, /run. References: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 https://lwn.net/Articles/436012/ This has already been adopted by Fedora, and it's something we've wanted in Debian for years (but settled on /lib/init/rw for FHS compliance). /run is wider in scope than /lib/init.rw, and will be used for transient writable data present from system startup to shutdown, which is not preserved across reboots, and will therefore supercede /var/run, /var/lock, /lib/init/rw and existing use of /dev and /etc as a place to put writable program state. Once set up by initscripts, I expect we will then need to replace /var/run and /var/lock with symlinks, which will require an additional change to base-files once /run is set up and functional. Bind mounting is an alternative, but bind mounting /run will hide files created earlier in the boot sequence, though it would be feasible for /var/lock. Updated patch attached. This allows the safe migration of /var/run and /var/lock by 1) dropping base-files ownership 2) ensuring their continued existence after dropping ownership This will permit initscripts/systemd to switch them to symlink or bind mount them at their discretion. The initscripts part of the /run migration is now almost complete. It would be great it we could have an updated base-files package, so we can have a versioned dependency on it to ensure that /run exists and allow the migration of /var/lock and /var/run. Many thanks, 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. diff -urN base-files-6.1.original/debian/1777-dirs base-files-6.1/debian/1777-dirs --- base-files-6.1.original/debian/1777-dirs 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/1777-dirs 2011-04-01 09:27:54.101365766 +0100 @@ -1,3 +1,2 @@ tmp -var/lock var/tmp diff -urN base-files-6.1.original/debian/changelog base-files-6.1/debian/changelog --- base-files-6.1.original/debian/changelog 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/changelog 2011-04-01 10:25:53.877078068 +0100 @@ -1,3 +1,15 @@ +base-files (6.1run0) unstable; urgency=low + + * Add /run. + * Remove /var/run and /var/lock. These locations will be migrated +to be symbolic links to /run and /run/lock, respectively, by +initscripts. + * Create /var/run and /var/lock in postinst. While base-files no +longer owns these directories, they should be present until adoped +by initscripts. + + -- Roger Leigh rle...@debian.org Fri, 01 Apr 2011 09:26:35 +0100 + base-files (6.1) unstable; urgency=medium * Changed issue, issue.net and debian_version to read wheezy/sid. diff -urN base-files-6.1.original/debian/directory-list base-files-6.1/debian/directory-list --- base-files-6.1.original/debian/directory-list 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/directory-list 2011-04-01 09:21:26.049156094 +0100 @@ -10,6 +10,7 @@ mnt proc root +run sbin tmp usr @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp diff -urN base-files-6.1.original/debian/postinst.in base-files-6.1/debian/postinst.in --- base-files-6.1.original/debian/postinst.in 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/postinst.in 2011-04-01 10:27:39.774537564 +0100 @@ -44,6 +44,12 @@ if [ ! -L /var/spool/mail ]; then ln -s ../mail /var/spool/mail fi + if [ ! -L /var/run ]; then +install_directory var/run 755 root + fi + if [ ! -L /var/lock ]; then +install_directory var/lock 1777 root + fi install_local_dir /usr/local install_local_dir /usr/local/share signature.asc Description: Digital signature
Bug#620157: base-files: Please add top-level /run
On Fri, Apr 01, 2011 at 10:40:52AM +0100, Roger Leigh wrote: On Wed, Mar 30, 2011 at 04:43:59PM +0100, Roger Leigh wrote: Attached is a patch for adding a new top-level directory, /run. References: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 https://lwn.net/Articles/436012/ This has already been adopted by Fedora, and it's something we've wanted in Debian for years (but settled on /lib/init/rw for FHS compliance). /run is wider in scope than /lib/init.rw, and will be used for transient writable data present from system startup to shutdown, which is not preserved across reboots, and will therefore supercede /var/run, /var/lock, /lib/init/rw and existing use of /dev and /etc as a place to put writable program state. Once set up by initscripts, I expect we will then need to replace /var/run and /var/lock with symlinks, which will require an additional change to base-files once /run is set up and functional. Bind mounting is an alternative, but bind mounting /run will hide files created earlier in the boot sequence, though it would be feasible for /var/lock. Updated patch attached. This allows the safe migration of /var/run and /var/lock by 1) dropping base-files ownership 2) ensuring their continued existence after dropping ownership This will permit initscripts/systemd to switch them to symlink or bind mount them at their discretion. The initscripts part of the /run migration is now almost complete. It would be great it we could have an updated base-files package, so we can have a versioned dependency on it to ensure that /run exists and allow the migration of /var/lock and /var/run. Updated patch attached. This fixed a single typo found in the previous patch. Thanks, 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. diff -urN base-files-6.1.original/debian/1777-dirs base-files-6.1/debian/1777-dirs --- base-files-6.1.original/debian/1777-dirs 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/1777-dirs 2011-04-01 09:27:54.101365766 +0100 @@ -1,3 +1,2 @@ tmp -var/lock var/tmp diff -urN base-files-6.1.original/debian/changelog base-files-6.1/debian/changelog --- base-files-6.1.original/debian/changelog 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/changelog 2011-04-01 16:23:49.081875258 +0100 @@ -1,3 +1,15 @@ +base-files (6.1run0) unstable; urgency=low + + * Add /run. + * Remove /var/run and /var/lock. These locations will be migrated +to be symbolic links to /run and /run/lock, respectively, by +initscripts. + * Create /var/run and /var/lock in postinst. While base-files no +longer owns these directories, they should be present until adopted +by initscripts. + + -- Roger Leigh rle...@debian.org Fri, 01 Apr 2011 09:26:35 +0100 + base-files (6.1) unstable; urgency=medium * Changed issue, issue.net and debian_version to read wheezy/sid. diff -urN base-files-6.1.original/debian/directory-list base-files-6.1/debian/directory-list --- base-files-6.1.original/debian/directory-list 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/directory-list 2011-04-01 09:21:26.049156094 +0100 @@ -10,6 +10,7 @@ mnt proc root +run sbin tmp usr @@ -32,8 +33,6 @@ var/lib/dpkg var/lib/misc var/local -var/lock var/log -var/run var/spool var/tmp diff -urN base-files-6.1.original/debian/postinst.in base-files-6.1/debian/postinst.in --- base-files-6.1.original/debian/postinst.in 2011-04-01 09:20:54.288929294 +0100 +++ base-files-6.1/debian/postinst.in 2011-04-01 10:27:39.774537564 +0100 @@ -44,6 +44,12 @@ if [ ! -L /var/spool/mail ]; then ln -s ../mail /var/spool/mail fi + if [ ! -L /var/run ]; then +install_directory var/run 755 root + fi + if [ ! -L /var/lock ]; then +install_directory var/lock 1777 root + fi install_local_dir /usr/local install_local_dir /usr/local/share signature.asc Description: Digital signature
Bug#620157: base-files: Please add top-level /run
Package: base-files Version: 6.1 Severity: normal Tags: patch Hi Santiago, Attached is a patch for adding a new top-level directory, /run. References: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 https://lwn.net/Articles/436012/ This has already been adopted by Fedora, and it's something we've wanted in Debian for years (but settled on /lib/init/rw for FHS compliance). /run is wider in scope than /lib/init.rw, and will be used for transient writable data present from system startup to shutdown, which is not preserved across reboots, and will therefore supercede /var/run, /var/lock, /lib/init/rw and existing use of /dev and /etc as a place to put writable program state. Once set up by initscripts, I expect we will then need to replace /var/run and /var/lock with symlinks, which will require an additional change to base-files once /run is set up and functional. Bind mounting is an alternative, but bind mounting /run will hide files created earlier in the boot sequence, though it would be feasible for /var/lock. Regards, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages base-files depends on: ii gawk [awk]1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii mawk [awk]1.3.3-15 a pattern scanning and text proces base-files recommends no packages. base-files suggests no packages. -- no debconf information diff -urN base-files-6.1.original/debian/changelog base-files-6.2/debian/changelog --- base-files-6.1.original/debian/changelog 2011-03-30 16:23:23.562397543 +0100 +++ base-files-6.2/debian/changelog 2011-03-30 16:35:15.875030171 +0100 @@ -1,3 +1,13 @@ +base-files (6.2) unstable; urgency=low + + * Add /run. /run is a replacement for /var/run, /var/lock and +/lib/init/rw, plus existing (ab)use of the writable tmpfs on /dev +and writing into /etc. It will be used to mount a tmpfs prior to +/var being mounted, and serve as a unified location for transient +writable data which should not be preserved across reboots. + + -- Roger Leigh rle...@debian.org Wed, 30 Mar 2011 16:29:02 +0100 + base-files (6.1) unstable; urgency=medium * Changed issue, issue.net and debian_version to read wheezy/sid. diff -urN base-files-6.1.original/debian/directory-list base-files-6.2/debian/directory-list --- base-files-6.1.original/debian/directory-list 2011-03-30 16:23:23.562397543 +0100 +++ base-files-6.2/debian/directory-list 2011-03-30 16:24:02.178847205 +0100 @@ -10,6 +10,7 @@ mnt proc root +run sbin tmp usr
