What to do about libc-client (imap)?
Warren Togami
wtogami at redhat.com
Mon Sep 20 04:34:06 UTC 2004
https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=imap&component=libc-client&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&Search=Search
imap has been a total disaster in the past, and now we provide both
dovecot and cyrus-imapd as robust alternatives. Since FC2, imap was
stripped down to the "c-client" library with no server functionality.
The only reason we keep libc-client, the library portion of imap, is so
php-imap can build.
But why do we keep php-imap? NOTHING we ship uses it. squirrelmail
long ago decided php-imap was unreliable and made their own implementation.
Our forced attempts to get rid of imap in FC2 were done in a confusing
manner which remains both a support burden for us, and a huge point of
frustration to users. [1] To make matters worse, 'libc-client' is a
confusing name which is too similar to 'glibc', and meaningless to all
developers.
Is this really worth more years of headache? Here are two proposals to
deal with this.
Proposed Option #1: Rename libc-client to imap-libs
===================================================
Bug #120873 outlines a workable alternative where
* Package name is no longer misleading.
* Installed in such a way to not conflict in files or deps with imap.
* imap in Extras, completely unsupported by Red Hat.
Pros: Reduced support burden on us as we wont have many more stupid
reports [1] from foolish users complaining that we've taken away their
ability to use an insecure, buggy and slow mail server.
Cons: We still would have responsibility of php-imap, which very few
people use.
Proposed Option #2: Get rid of imap/libc-client completely
==========================================================
* Remove imap and libc-client from all future distributions.
* imap in Extras, completely unsupported by Red Hat.
Pros: No support burden for us.
Foolish users can use it if they really wish.
Cons: Difficult (but not impossible) to build php-imap
Not our problem. Extras can provide this.
I personally would much prefer Option #2 because it reduces the support
burden on Red Hat, for software that NONE of us care about. Any other
opinions?
Warren Togami
wtogami at redhat.com
[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132928
Some guy complains about imap conflicting with libc-client "for no reason".
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132933
The same guy realizes imap sucks, and says dovecot should Obsolete imap.
I point at Bug #120678 below as an example of why this is a bad idea.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120678
libc-client conflicts with cyrus-imapd (Earlier failed attempt to
forcefully remove imap)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123580
Confusion due to php-imap...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120873
Rename libc-client to imap-libs. This or removal of libc-client are our
best options.
More information about the fedora-devel-list
mailing list