Ansgar Burchardt <ans...@debian.org> writes:
> Seconded.
> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).
> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.
> To support merged-<file>/usr</file> systems, packages must not
> install files in both <file>{path}</file> and
> <file>/usr/{path}</file>.
> In case a file gets moved between <file>{path}</file> and
> <file>/usr/{path}</file> and a compatibility symlinks is needed,
> the symlink must be managed in such a way that it will not
> break when, for example, <file>/bin</file> and <file>/usr/bin</file>
> are the same directory.
I took the liberty of tweaking this a bit when applying this patch, and
came up with the following:
--- a/policy.sgml
+++ b/policy.sgml
@@ -8634,6 +8634,22 @@ fi
programs must be renamed.
</p>
<p>
+ To support merged-<file>/usr</file> systems, packages must not
+ install files in both <file><var>path</var></file>
+ and <file>/usr/<var>path</var></file>. For example, a package
+ may not install both <file>/bin/example</file>
+ and <file>/usr/bin/example</file>.
+ </p>
+ <p>
+ If a file is moved between <file><var>path</var></file>
+ and <file>/usr/<var>path</var></file> in revisions of a Debian
+ package, and a compatibility symlink at the old path is needed,
+ the symlink must be managed in a way that will not break
+ when <file><var>path</var></file>
+ and <file>/usr/<var>path</var></file> are the same underlying
+ directory due to symlinks or other mechanisms.
+ </p>
+ <p>
Binary executables must not be statically linked with the GNU C
library, since this prevents the binary from benefiting from
fixes and improvements to the C library without being rebuilt
Now committed for the next Policy release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
