Some voices: From: Henrique de Moraes Holschuh <hmh AT debian.org> Date: Mon, 3 May 2004 15:52:53 -0300 Debian has been renaming any potential offenders (reconstruct, master, etc) by prefixing them with "cyr" for a VERY long time now. I will do so for Cyrus 2.2 as well, for every potential offender that has not a "cyr" or "cyr_" prefix already... [...] From: Rob Siemborski <rjs3 AT andrew.cmu.edu> Date: Mon, 3 May 2004 11:04:32 -0400 (EDT) I don't know what we can do in the next 4 days that will solve the problem for Fedora. Even if we were to release a new version that corrected the problem in that time (unlikely), I highly doubt they'd be willing to adopt it just to change the name. For what its worth, our experience in the past has been that package mantainers have delt with conflicts like this on their own (in several cases, for example, "deliver" has been renamed to "cyrdeliver", and there is also a conflict with the name of the postfix "master" process -- not to mention "imapd" which conflicts fairly directly with the UW server) quite successfully. I don't see why this is significantly any different (especially when it can be delt with, minimally, in the way that FreeBSD does). Changing the binary name in our release causes all of our users to have to fix their systems to reference the new name when they upgrade. This is not something I take lightly, and would strongly prefer not to do. I appreciate the problems with the namespace conflict, but if we were to do this for all of our binaries every time a conflict was discovered, I suspect we would quickly go mad. FWIW, I'm perfectly fine with Fedora changing the Cyrus fetchnews to cyrfetchnews in order to fix their namespace conflict. Beyond that, I'm not sure what I can do that can help before May 7 anyway. [...]
