What to do about libc-client (imap)?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx

[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.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux