Hi,

Roger Leigh <rle...@debian.org> (04/04/2011):
> +                  additionally allowed: <file>/run</file>,
> +               <file>/sys</file> and <file>/selinux</file>.
> +               <footnote>The <file>/run</file> directory is a
> +                  replacement for <file>/var/run</file>, and its
> +                  subdirectory <file>/run/lock</file> is a replacement for
> +                  <file>/var/lock</file>.  These changes have been
> +                  adopted by most distributions and have been proposed
> +                  for inclusion in a future revision of the FHS.  Both
> +                  are expected to be temporary filesystems, whose
> +                  purpose is storage of ephemeral system state which
> +                  should not be preserved across reboot.

“reboots” if you want to stay consistent with the hunk below.

> +                  The <file>/sys</file> and <file>/selinux</file>
> +                  directories are used as mount points to mount
> +                  virtual filesystems to get access to kernel
> +                  information.</footnote>
>                  </p>
>                </item>
>             <item>
> @@ -6719,14 +6730,18 @@ test -f <var>program-executed-later-in-script</var> 
> || exit 0
>         </p>
>  
>         <p>
> -         <file>/var/run</file> and <file>/var/lock</file> may be mounted
> -         as temporary filesystems<footnote>
> -             For example, using the <tt>RAMRUN</tt> and <tt>RAMLOCK</tt>
> -             options in <file>/etc/default/rcS</file>.
> -         </footnote>, so the <file>init.d</file> scripts must handle this
> -         correctly. This will typically amount to creating any required
> -         subdirectories dynamically when the <file>init.d</file> script
> -         is run, rather than including them in the package and relying on
> +         <file>/var/run</file> and <file>/var/lock</file> should be
> +         symlinks to <file>/run</file> and <file>/run/lock</file>,
> +         respectively, which are temporary filesystems whose
> +         contents are not preserved across reboots.  This

(here)

> +         arrangement may also be satisfied through equivalent
> +         means, for example bind or nullfs mounts.  Because the
> +         presence of files or directories in any of these
> +         directories is not guaranteed, <file>init.d</file> scripts
> +         must handle this correctly. This will typically amount to
> +         creating any required subdirectories dynamically when
> +         the <file>init.d</file> script is run, rather than
> +         including them in the package and relying on
>           <prgn>dpkg</prgn> to create them.
>         </p>
>       </sect1>

Otherwise, looks good to me.

Seconded (w/ or w/o that 1-char change).

KiBi.

Attachment: signature.asc
Description: Digital signature

Reply via email to