Bug 115535 - rfe: bring php-imap back for FC2
rfe: bring php-imap back for FC2
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2004-02-13 07:10 EST by Kaj J. Niemi
Modified: 2007-11-30 17:10 EST (History)
7 users (show)

See Also:
Fixed In Version: 4.3.4-11
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-07 15:13:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
libc-client.spec (3.46 KB, text/plain)
2004-02-24 12:58 EST, Kaj J. Niemi
no flags Details
libc-client.spec 2002e-4, fixes outstanding issues (4.17 KB, text/plain)
2004-04-06 17:29 EDT, Kaj J. Niemi
no flags Details
Updated imap-2002e-shared.patch, CFLAGS (and RPM_OPT_FLAGS) are now used during compilation (2.23 KB, text/plain)
2004-04-06 17:31 EDT, Kaj J. Niemi
no flags Details

  None (edit)
Description Kaj J. Niemi 2004-02-13 07:10:13 EST
Description of problem:
Please reintroduce php-imap (removed starting 4.3.4-4) to the FC2 tree.

There seems to be a lot of php code out there which uses the imap
functions. These include horde.org's IMP, FogCreek Software's FogBUGZ,
etc. No matter what people think about php in general it is a useful
scripting language for certain applications ;-)

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


Version-Release number of selected component (if applicable):
Comment 1 Joe Orton 2004-02-13 07:20:58 EST
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?
Comment 2 Kaj J. Niemi 2004-02-13 07:28:17 EST
Sure thing.
Comment 3 Kaj J. Niemi 2004-02-14 15:44:08 EST
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.


Comment 4 Bernd Bartmann 2004-02-15 14:09:09 EST
IMAP support is absolutely mandatory. There are several web mail
applications (e.g. TWIG) that rely on this.
Comment 5 Miles Sabin 2004-02-15 14:36:04 EST
Squirrelmail also requires php-imap.
Comment 6 Tom Diehl 2004-02-15 14:41:23 EST
PLEASE put it back or provide some kind of alternative. I need
squirrelmail or some form of webmail.
Comment 7 William Hooper 2004-02-15 14:48:01 EST
Squirrelmail doesn't require php-imap, it has it's own IMAP functions.
Comment 8 Bill Nottingham 2004-02-16 02:18:53 EST
FWIW, c-client is probably one of the main reasons the uw-imapd was
removed. :/
Comment 9 Joe Orton 2004-02-16 02:31:22 EST
Bill, what are the reasons? Can you follow up on the fedora-devel thread?
Comment 10 Bill Nottingham 2004-02-16 02:35:05 EST
Bad security record.
Comment 11 Bernd Bartmann 2004-02-16 05:01:02 EST
"Bad security record" is not an excuse for removing functionality and
not providing an alternative.
Comment 12 Bill Nottingham 2004-02-16 13:59:33 EST
Alternatives for imapd *are* included, all of which have much better
security records than the c-client code in uw-imap.
Comment 13 Bernd Bartmann 2004-02-16 14:02:17 EST
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.
Comment 14 Bill Nottingham 2004-02-16 14:06:03 EST
It's the same code, though, with the same problems.
Comment 15 Bryan Dobson 2004-02-16 14:20:41 EST
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.
Comment 16 Kaj J. Niemi 2004-02-16 14:26:20 EST
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.

Comment 17 Kaj J. Niemi 2004-02-23 06:07:19 EST
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. :)

Comment 18 Bryan Dobson 2004-02-23 10:29:25 EST
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
Comment 19 Tom Diehl 2004-02-23 10:45:01 EST
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?
Comment 20 Joe Orton 2004-02-24 08:37:42 EST
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?
Comment 21 Bill Nottingham 2004-02-24 12:06:52 EST
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.
Comment 22 Joe Orton 2004-02-24 12:18:02 EST
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?
Comment 23 Kaj J. Niemi 2004-02-24 12:58:00 EST
Created attachment 98001 [details]

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.
Comment 24 Kaj J. Niemi 2004-04-06 13:07:41 EDT

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

Thanks :)
Comment 25 Kaj J. Niemi 2004-04-06 13:08:22 EDT
Uh I guess I meant Joe, not Josh.
Comment 26 Joe Orton 2004-04-06 13:51:00 EDT
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.
Comment 27 Kaj J. Niemi 2004-04-06 17:29:17 EDT
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.
Comment 28 Kaj J. Niemi 2004-04-06 17:31:37 EDT
Created attachment 99163 [details]
Updated imap-2002e-shared.patch, CFLAGS (and RPM_OPT_FLAGS) are now used during compilation
Comment 29 Joe Orton 2004-04-06 17:49:11 EDT
Looking good, thanks Kaj.  I've requested that the "libc-client"
package is added to the buildsystem and will get this built.
Comment 30 Joe Orton 2004-04-07 09:22:53 EDT
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.
Comment 31 Joe Orton 2004-04-07 15:13:10 EDT
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.
Comment 32 Kevin Fries 2004-05-26 15:02:53 EDT
I am getting huge dependency errors.

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

# rpm -qa | grep php

# 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
Comment 33 Joe Orton 2004-05-26 15:05:43 EDT
Kevin, that's bug 123580.

Note You need to log in before you can comment on or make changes to this bug.