Bill Allombert wrote:
> So to recap, Marco proposal is
>
> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..74f0a3b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8508,6 +8508,21 @@ fi
> renamed. If a consensus cannot be reached, <em>both</em>
> programs must be renamed.
> </p>
> +
> + <p>
> + To support merged /usr systems, packages must not install
a
> + file in <file>/usr/bin</file> with the same name as a file
in
> + <file>/bin</file> or a file in <file>/usr/sbin</file> with
the
> + same name as a file in <file>/sbin</file>.
> + If such a compatibility symlink is needed then it must be
> + managed in the maintainer scripts in a way that will not
break
> + when e.g. <file>/usr/bin</file> and <file>/bin</file> are
the
> + same directory.
> + Packages must not install a file in <file>/usr/lib</file>
(or
> + one of its subdirectories) with the same name as a file in
> + <file>/lib</file> (or the corresponding subdirectory).
> + </p>
> +
> <p>
> Binary executables must not be statically linked with the
GNU C
> library, since this prevents the binary from benefiting
from
>
> Who is seconding this ?
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.
Ansgar
