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

What to do about libc-client (imap)?

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 redhat com

Some guy complains about imap conflicting with libc-client "for no reason".

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.

libc-client conflicts with cyrus-imapd (Earlier failed attempt to forcefully remove imap)

Confusion due to php-imap...

Rename libc-client to imap-libs. This or removal of libc-client are our best options.

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