Bug#759492: File conflicts between /bin and /usr/bin
Hi!
On Wed, 2014-08-27 at 09:59:10 -0700, Russ Allbery wrote:
> Package: debian-policy
> Severity: wishlist
>
> I could have sworn we already had a bug open about this, but I couldn't
> find it. If someone else does find it, please merge.
I'm not sure if you were thinking about #562863? Although that seems
more generic.
> It's worthwhile to make this change even apart from this possible merge
> since having two programs with the same name at different points in the
> PATH is confusing. Note that this bug does not deal with the separate
> problem that Policy is not clear abot applying the rule against
> conflicting binaries to binaries elsewere on the PATH (conflicts between
> /usr/games/foo and /sbin/foo, for example). I believe there is a
> separate bug open about that, and we should also resolve that issue.
It's only confusing if they are different binaries, as long as they are
just symlinks coming from the same binary package, I think it's fine
and standard practice.
> I wanted to open this discussion, but it's not clear whether we're ready
> yet to actually merge this patch. On my local system, I have the
> following conflicts, all of which are symlinks and therefore don't pose
> a functionality problem:
>
> lrwxrwxrwx 1 root root 10 May 20 2013 chacl -> /bin/chacl*
> lrwxrwxrwx 1 root root 13 Feb 17 2013 dumpkeys -> /bin/dumpkeys*
> lrwxrwxrwx 1 root root 12 May 20 2013 getfacl -> /bin/getfacl*
> lrwxrwxrwx 1 root root 9 Jun 5 2013 less -> /bin/less*
> lrwxrwxrwx 1 root root 13 Jun 5 2013 lessecho -> /bin/lessecho*
> lrwxrwxrwx 1 root root 13 Jun 5 2013 lessfile -> /bin/lesspipe*
> lrwxrwxrwx 1 root root 12 Jun 5 2013 lesskey -> /bin/lesskey*
> lrwxrwxrwx 1 root root 13 Jun 5 2013 lesspipe -> /bin/lesspipe*
> lrwxrwxrwx 1 root root 13 Feb 17 2013 loadkeys -> /bin/loadkeys*
> lrwxrwxrwx 1 root root 12 May 20 2013 setfacl -> /bin/setfacl*
> lrwxrwxrwx 1 root root 10 Apr 12 16:34 touch -> /bin/touch*
> lrwxrwxrwx 1 root root 10 Jul 27 2013 which -> /bin/which*
>
> These symlinks would have to be removed to follow this new Policy rule,
> which means that one of the two paths by which those programs can be
> addressed would go away. Removing, at least, /usr/bin/which would break
> various packages:
Disallowing such compatibility symlinks means that those programs
can no longer be moved between directories w/o possibly breaking
things that use absolute pathname, which should be considered a bug
in Debian, but is something that still happens. And local admin
policies might be different, so leaving some transition time is
always good.
W/o these the transitions from dpkg to GNU install-info would have
been pretty dire. Or moving update-alternatives, dpkg-divert and
dpkg-statoverride from /bin to /usr/bin. But there's many similar
examples.
Thanks,
Guillem
Reply to: