Paride Legovini <p...@ninthfloor.org> writes: > However, there are clearly cases where renaming binaries makes several > people unhappy (most likely: the package maintainers, upstream, people > writing scripts, users of different distributions), while not making a > single user happier. This is especially true with low popcon packages > with a small use case intersection.
If the packages conflict, though, this is extremely unfriendly to the users who do want to use both packages. They cannot use both packages on the same OS installation, and have to resort to chroots or VMs or containers, which is a lot of extra complexity. I'm therefore in favor of keeping Policy's prohibition on using Conflicts for this case; maybe a combination of two packages will get lucky and there will be literally no users who want to use both at the same time, but it's very hard to tell when that's the case and the failure mode is ugly. I kind of like the solution of putting the binaries in a different directory. This is also a little irritating, since users have to add an additional directory to their PATH, but they only have to do that once and it works consistently going forward, and they can still use the other program. It's not totally unheard of to have to modify PATH to use a package, particularly one that wants to use a bunch of very generic command names. That was always the official way to use MH, for example. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
