I've read bug 120873, and I understand why this RPM isn't going to be renamed and the server portion of it isn't going to be put back. But is there any reason why we need to stick with a version of the c-client library that's over three years old? The folks who maintain php-imap are certainly expecting a current version of the library, and surely changes have been made to it since 2002. So, if FC is going to continue to support the library for the sake of php-imap, then shouldn't the library RPM be updated to a current version? In other words, I think I'm submitting a different bug from bug 120873, since that seemed to be about renaming the RPM and including support for building the server, and what I'm suggesting is leaving things as they are now but with a more recent version of the library. If you disagree and think this is the same issue, feel free to close this ticket, but do please consider offering some explanation for why we should stick with a 3-year-old library :-). Thanks.
No, there's nothing preventing libc-client being updated to a newer version other than lack of round tuits. If you have some round tuits to use up and submit patches here that would certainly be useful!
See http://stuff.mit.edu/~jik/libc-client-2004g-1.src.rpm. I minimally tested php-imap with it, and it appears to work. This is based on the most recent libc-client SRPM in FC devel.
Thanks Jonathan. I've built this in Raw Hide.