On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote: > I'm trying to figure out a solution for RC bug #592242. The short > summary of this bug is a package A that conflicts with a package B due > to a name clash in /usr/bin. The programs in question do not provide the > same functionality, hence the alternatives systems cannot be used. > Debian policy 10.1 states: > > 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...) > > Since renaming is not an option due to large side-effects in the > packages in question, I declared a package conflict between A and B and > uploaded a new version. However, various parties expressed their > concerns with this "solution".
You forgot the rest of the paragraph: | 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. > However, the situation of #592242 is different. The package (fsl) that > conflicts with other packages (e.g. cyrus-clients-2.2) only installs a > number of symlinks to tools of a large analysis suite into /usr/bin. The > actual suite is installed by another package (fsl-4.1) that does not > conflict with other packages. Hence users will always be able to > install this suite in combination with any other package. The only > purpose of the conflicting package is to allow for a more convenient > out-of-the-box setup for people who run this analysis suite as the > primary software in their research labs. If, for some reason, they happen > to run any of the conflicting packages they can still use the suite with no > drawbacks other than reduced initial setup convenience. I would consider the names of the binaries to generic anyway. > Is there something that is intended by policy 10.1 that I am missing? Yes, at least one package have to rename, and this is a must clause. Bastian -- Captain's Log, star date 21:34.5... -- 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/20100814111245.ga3...@wavehammer.waldi.eu.org
