On Mon, 07 Mar 2016, Ansgar Burchardt wrote: > 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 also second this improved wording or any other wording in the same spirit. I agree it's better than the initial wording. Though it would be good to list the most common values of "{path}" (and you want to use <replaceable> path</replaceable> in docbook instead of {path}). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
signature.asc
Description: PGP signature