[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fwd: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9]



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.

[...]



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]