Re: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9
[recipient list purged] On Mon, 3 May 2004, Rob Siemborski wrote: > On Mon, 3 May 2004, Henrique de Moraes Holschuh wrote: > > > > 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 > > > > There is one answer for that, which is to prefix everything that is not a > > service with cyr_ for 2.3, and have all services installed in a separate > > directory (which is already possible, but it is not strongly suggested or > > anything). After all, services are to be run by master, only... I'm not a big fan of prefixes for executables: we already have file namespace separation thanks to directories. Not precisely knowing _where_ to put them is not an excuse. /usr/libexec/cyrus-imapd seems fine to me. Most executables are neither general purpose (/usr/bin) nor for sysops (/usr/sbin) as they are required to run as the 'cyrus' (or whatever) user. Adding /use/libexec/cyrus-imapd to $PATH for the cyrus user only sounds sane enough. If a command can be sensibly used by any user, it belongs to the system bin directory, but the prefix in the name is natural in this case: cyradm comes to mind, it's so natural that it already has it. B-) > > The problem is more the man pages, really (as it is in this case). That's close to impossible to solve for developers. It has to be dealt at package creation time (sed/perl). It's more a deficiency in the old glorious UNIX man system than anything else. But recent man executables have provisions to handle this nicely btw, just few distros fully make use of them. man on fedora has MANPATH and MANPATH_MAP. MANPATH_MAP fits the separate directory approach well. Just install manpages in /usr/share/cyrus-imapd/man or something. Just my 2c. > > FWIW, Bug 2425 is open now to address this. I'm not sure when a good time > to do so is, but certainly 2.3 is the earliest possible time. > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > --- > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9
On Sun, 2 May 2004, Matthias Andree wrote: > Given that Cyrus-IMAPd 2.2.3 has been released only this January, and > has not yet been adopted by all distributions (most are still shipping > Cyrus-IMAPd 2.1.N), renaming fetchnews to cyr_fetchnews would have > little impact _now_ but be a major inconvenience later. > > Note that distributors HAVE TO take action, and to avoid every > distributor using their own name, causing confusion among our users, > let's address this from the top level. > > Could you change your fetchnews program's name to cyr_fetchnews or > similar? I am offering to rename leafnode's fetchnews to something else > (leafnode-fetchnews, ln_fetchnews, to be determined) in the next major > version of leafnode, leafnode-2.0.0 (probably 2nd half 2004) in return. > > I have marked the Subject "URGENT" because Fedora has scheduled a code > freeze for May 7th (next Friday), I'd hope that we can resolve the > problem before then. Hi Matthias, 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. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9
On Mon, 3 May 2004, Henrique de Moraes Holschuh wrote: > > 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 > > There is one answer for that, which is to prefix everything that is not a > service with cyr_ for 2.3, and have all services installed in a separate > directory (which is already possible, but it is not strongly suggested or > anything). After all, services are to be run by master, only... The problem is more the man pages, really (as it is in this case). FWIW, Bug 2425 is open now to address this. I'm not sure when a good time to do so is, but certainly 2.3 is the earliest possible time. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: URGENT: Naming conflict in Cyrus-IMAP 2.2 vs. leafnode 1.9
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... I don't know what to do with borderline stuff like mbpath, though. I might end up prefixing everything with "cyr" for completeness. The services aren't a problem, since I package them in a directory of their own. I document this throughoutly on the READMEs, and it is an already more or less well known fact that such renames are sometimes done in Cyrus distributions. So fetchnews would just be one more player in this rename dance. On Mon, 03 May 2004, Rob Siemborski wrote: > 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). How does FreeBSD deal with this? I'm curious :) > 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 There is one answer for that, which is to prefix everything that is not a service with cyr_ for 2.3, and have all services installed in a separate directory (which is already possible, but it is not strongly suggested or anything). After all, services are to be run by master, only... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
