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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827173240.ga29...@gaara.hadrons.org
