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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607203737.GF3194@burratino
