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