Bug#759492: File conflicts between /bin and /usr/bin

[Russ Allbery <rra@debian.org>]

Ansgar Burchardt <ansgar@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>