Bug#759492: File conflicts between /bin and /usr/bin
On Sat, Mar 05, 2016 at 02:08:34AM +0100, Marco d'Itri wrote:
> On Jan 24, Marco d'Itri <md@Linux.IT> wrote:
>
> > > I wanted to open this discussion, but it's not clear whether we're ready
> > > yet to actually merge this patch.
> > We are now: there are less than 10 packages left which have not been
> > fixed, all of them with patches
> We are down to 4 broken packages left (safe-rm, ksh, elvis-tiny,
> yp-tools), none of them matter and I do not expect that the maintainers
> will care until they will be uninstallable.
> How can we move forward with this policy change?
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 ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: