Bug 115535

Packaging c-client separately was one of the options discussed but we
didn't really come to a conclusion on this before the test1 release. 
Can you bring this up on fedora-devel so we can have a conclusion?

Sure thing.

One reply on the mailing list in favor of having it back, great. :-)

I built a SRPM of the c-client with both a shared (the main package)
and a static library (the devel package). I guess the %doc section
could use some trimming but that can be done later.

<http://www.a51.org/sw/fedora/c-client-2002e-0.1.src.rpm>

IMAP support is absolutely mandatory. There are several web mail
applications (e.g. TWIG) that rely on this.

Squirrelmail also requires php-imap.

PLEASE put it back or provide some kind of alternative. I need
squirrelmail or some form of webmail.

Squirrelmail doesn't require php-imap, it has it's own IMAP functions.

FWIW, c-client is probably one of the main reasons the uw-imapd was
removed. :/

Bill, what are the reasons? Can you follow up on the fedora-devel thread?

Bad security record.

"Bad security record" is not an excuse for removing functionality and
not providing an alternative.

Alternatives for imapd *are* included, all of which have much better
security records than the c-client code in uw-imap.

Bill, we don't need alternatives but imapd, but for php-imap. This
module provides the php functions to access an imap server not to be
an imap server.

It's the same code, though, with the same problems.

Agreed with everyone else here, that php-imap is essential, I was
blown away when I found that it had been outright removed. I use
Horde/IMP and it requires the php-imap module be in place. In the
interm I can use Squirrelmail but there are other programs that
require this as well which are going to come up.

Bill, you might as well then drop sendmail and php from FC2 since both
have historically been laced with security issues and there are two
alternatives available in FC2 for both of them. ;-)

Having maintained a 120k account uw-imap installation over NFS I do
agree it is pretty much a PITA to have around. Cyrus and dovecot are
more than enough to replace uw-imap.

The discussion was about the c-client library however.

I did a quick poll among the sysadmins I know and everyone of them
said they'd expect php come with imap packaged.

Since we're talking about FC2 instead of RHEL3 license seats I don't
have a business case (also known as the "we'll buy for x amount from
you if you implement this" RFP/RFE requirement) beyond stating it
would save a lot of people a lot of work maintaining a shadow php version.

Since the FC2 freeze date is coming up.. could we get a go/no go on
this, please. Seems to me the consensus would be in favor of so far. :)

Agreed. I am using Squirrelmail and a few other programs instead of
the others that I typically use. All the other distros have an
php-imap solution now except this one, which should be the best of the
lot.

Are there any alternatives out there or is the uw crap all that is
available? It might be easier to get this back into fedora if there
was a non-UW solution. Given that most people feel that UW code is not
easily maintainable and their non-free license, I understand the
reason to rid the distro of it but IMO we need an alternative. The
problem is that to my knowledge there is none and I do not have the
skills to create one. :-( I suspect that if it is permanently rm'd
that someone who really needs it will repackage it but...

Red Hat what say yee?

The consensus has always been that bringing back php-imap would be a
good thing, there is no debate there really.

Nobody has spoken positively about adding back c-client.  Bill, who
will make this decision, or can you: would a libc-client package be
accepted for inclusion in FC2 if someone wrote one?

I'm not particularly enamored of the c-client code, but if someone
wants to step up and maintain it, it's not a huge deal for FC2.

OK, Kaj, now is the time to take you up on your kind offer! :)

> Would packaging only the UW c-client library help you out at all or
> was the removal of UW IMAP a licensing related thing?

Can you produce a "libc-client.spec" spec file suitable for packaging
c-client, and send it in to fedora-devel for review?

Created attachment 98001 [details]
libc-client.spec

Ok. Attached is a libc-client.spec to start the discussion with. The srpm can
be found at <http://www.a51.org/sw/fedora/>. I'll post a followup to my
original thread in shortly.

Josh,

is there anything else you require for libc-client/php-imap before FC2?

Thanks :)

Uh I guess I meant Joe, not Josh.

Josh, Joe, Jim, anything will do.  Actually I think I was waiting on
feedback on the $RPM_OPT_FLAGS issue I mentioned on fedora-devel-list.

Created attachment 99162 [details]
libc-client.spec 2002e-4, fixes outstanding issues

Uh, okay, this is my bad... I seem to have completely missed your mail on the
mailing list in early March (the update to 2002e-3), found it via gmane.

Created attachment 99163 [details]
Updated imap-2002e-shared.patch, CFLAGS (and RPM_OPT_FLAGS) are now used during compilation

Looking good, thanks Kaj.  I've requested that the "libc-client"
package is added to the buildsystem and will get this built.

First time through libc-client.so.1 came out with no dependency on
libc.so.6, which was rather catastrophic, but second time through it
worked OK.   Should be in the Raw Hide push today.

php-4.3.4-11 built the imap subpackage without issues; in Raw Hide
tomorrow: let me know whether it actually works or not, please! 
Thanks for your work on this, Kaj.

I am getting huge dependency errors.

apt-get wants to remove PHP then complains that PHP will not be installed

# rpm -qa | grep php
php-4.3.4-11
php-pear-4.3.4-11
php-ldap-4.3.4-11
php-pgsql-4.3.4-11

# apt-get install php-imap
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  php-imap: Depends: php (= 4.3.4-11) but it is not going to be installed
E: Broken packages

-------------------------------------------
As you can see from the above, the dependency is already installed,
and thus this is an incorrect error message

Kevin, that's bug 123580.