Bug#676561: debian-policy: Please clarify important restriction on use of /run
Hi Roger,
Roger Leigh wrote:
> It's come to my attention that some developers are using /run
> without a versioned initscripts dependency, which will break
> upgrades from squeeze.
Thanks. This requirement does seem worth documenting.
[...]
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -6281,6 +6281,16 @@ install -m644 debian/shlibs.<var>package</var> debian/<var>package</var>/DEBIAN/
> in <file>/run</file> should be stored on a temporary
> file system.
> </p>
> + <p>
> + Note that for the wheezy release, <file>/run</file>
> + may not be used without a depends on <tt>initscripts
> + (>= 2.88dsf-13.3)</tt>. Without this
> + dependency, <file>/run</file> is not guaranteed to
> + exist or to be writable. Please refer to the
> + detailed guidance on
> + the <url id="http://wiki.debian.org/ReleaseGoals/RunDirectory"
> + name="Debian wiki">.
Might be clearer to make it a simple, self-contained normative
requirement --- e.g., imitating 2361862a ("New Breaks dependency
field"):
Packages must not assume the <file>/run</file> directory
exists or is usable without a dependency on <tt>initscripts
(>= 2.88dsf-13.3)</tt> until the stable release of Debian
supports <file>/run</file>.
[...]
> --- a/upgrading-checklist.sgml
> +++ b/upgrading-checklist.sgml
> @@ -74,7 +74,13 @@ Released February, 2012.
> directories apply to these directories as well. Backward compatibility
> links will be maintained and packages need not switch to
> referencing <file>/run</file> directly yet. Files in <file>/run</file>
> - should be stored in a temporary file system.
> + should be stored in a temporary file system. Note that for the wheezy
> + release, <file>/run</file> may not be used without a depends on
> + <tt>initscripts (>= 2.88dsf-13.3)</tt>. Without this dependency,
> + <file>/run</file> is not guaranteed to exist or to be writable.
> + Please refer to the detailed guidance on the
> + <url id="http://wiki.debian.org/ReleaseGoals/RunDirectory"
> + name="Debian wiki">.
I think a new upgrading-checklist item attached to the next policy
version would work even better, since packagers that already made a
mistake would notice while looking over the new entries.
Hope that helps,
Jonathan
Reply to: