Thibaut Paumard <paum...@users.sourceforge.net> writes: > As I understand it, Policy is broken here: if the two binaries where > installed in /usr/bin, it would be fine (Policy-wise) to Conflict.
Our current Policy specifically prohibits that. See Policy 10.1: Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via "alternatives" or the "Conflicts" mechanism. See Maintainer Scripts, Section 3.9 and Conflicting binary packages - Conflicts, Section 7.4 respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed. If there's a gap in Policy, it's actually around the current situation where the two binaries don't have the same paths, since it's not clear what Policy means by "filename". But it's pretty obvious that the intent of Policy is also to prohibit binaries with different functionality in sbin and bin, given how unstable of a situation that creates with varying PATH. Now, that certainly doesn't rule out the sorts of solutions we're talking about. As I mentioned elsewhere, the point of Policy is to make the system usable, not to have packages follow Policy just for their own sake. If we come up with a better way of solving this situation that requires an exception to Policy for transitional or compatibility packages, I think that's fine. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vck9cfb6....@windlord.stanford.edu