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 :-).
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.