Good evening,
since the final release of the Zarafa Collaboration Platform (ZCP) 7.2 about 3 weeks ago, I received multiple e-mails about when the packages in Fedora and EPEL will be updated from latest 7.1.x to 7.2.0. The answer is unfortunately quite simple: Not at all - or at least not by me.
With this e-mail I try to answer all questions that arrived regarding the future of Zarafa in Fedora and EPEL.
What does that mean exactly for me? As of writing this means for: - Fedora 22 (and newer, including Rawhide): No Zarafa in Fedora at all. - Fedora 21 and 20: Zarafa 7.1.x until the Fedora release is EOL. Fedora 21 will be maintained until 1 month after the release of Fedora 23 [1]. - Fedora EPEL 7, 6 and 5: Zarafa 7.1.x at least until the Fedora 21 release goes EOL. Fedora 21 will be maintained until 1 month after the release of Fedora 23 [1]. In case Zarafa drops the support for the 7.1 series before EOL of Fedora 21 I might do so as well on all Fedora and EPEL branches [2]. It is hard to maintain a huge software like Zarafa if there is no more upstream support.
Why don't you want to update Zarafa in Fedora? I finally retired Zarafa in Fedora Rawhide in December 2014 because I simply do not want to maintain the package anymore and nobody else stepped up so far to do this work [3].
I need Zarafa 7.2 because of the "Revamped OpenSSL stack"! If you use the Zarafa packages from Fedora or EPEL, it is already available since October 2014. I wrote that patch in March 2014 and proposed it to Zarafa. Further more only in Fedora and EPEL RPM packages there is ECDHE support (Elliptic curve Diffie-Hellman) for PFS (Perfect Forward Secrecy). This patch is from April 2014 and has not yet been merged into the Zarafa mainline [4] [5].
Which other features or patches did you add to Zarafa in Fedora and EPEL that might go away if I switch to other packages? All of them are listed at the Fedora GIT and can be downloaded there [6], most of them have not yet been merged to the Zarafa mainline.
What about the official RPM packages from zarafa.com for RHEL and CentOS? Zarafa announced its new direction in the beginning of 2015 and part of that is that in the future only Zarafa's commercial customers will have access to tested binaries (= RPM packages) [7].
What about Zarafa packages on other distributions? Honestly, I do not know because I am a Fedora contributor. As of writing, I know that Debian is not shipping Zarafa at all [8] and Mageia is shipping it but retired it for the future releases [9] as well.
As a Zarafa user, what options do I have? As of writing you could: - Takeover and resurrect the Zarafa package in Fedora. - Compile Zarafa completely from source yourself. - Migrate to another groupware/solution. - Get a commercial customer of Zarafa. - Freeze the state of your system (not recommented for security reasons).
Do you want to push me to get a commercial customer of Zarafa or to migrate to another groupware? No.
Is it complicated to build RPM packages of Zarafa? It's not rocket science at least. However it is neither easy nor trivial to build high quality RPM packages for a Linux distribution that aims to be the leader in latest of free and open source software. But if you are looking for a challenge, you are welcome to take it!
Will you help me if I resurrect the Zarafa package in Fedora? Maybe, but if so, then only up to a certain point. I am not interested in getting the new co-maintainer of the Zarafa package in Fedora, sorry.
What are the known issues and/or blockers if I resurrect Zarafa in Fedora? - Zarafa depends on libvmime which needs to be resurrected then as well. The issue here is, that libvmime is under heavy development for years now, has thus unfortunately not really a stable API or ABI. According to my knowledge the last libvmime version that Zarafa works with is upstream GIT b5927243a27b30cad4b303308c953d6a2d48bc0b. Shortly after that commit, upstream broke API and ABI compatibility. A fix isn't impossible but have a look to the history of non-working zarafa-7.1.4-libvmime092.patch [10]. - Zarafa WebAccess switched with the release of Zarafa 7.2 to complementary support [11] and this is about 6 months before socalled end-of-lifecycle milestone [12]. Given that browsers are changing often there might be one or the other issue with latest browsers that might need to be addressed. - Simply switching from Zarafa WebAccess to the Zarafa WebApp doesn't work for Fedora because the WebApp bundles lots and lots of 3rd party software such as at least pear/Services_JSON, pear/XML_Serializer, TinyMCE, Ext JS, BenExile/Dropbox, sabre/dav, JW FLV Player (including a binary flash blob), oauth2-php, pdfbox, Httpful, xmlrpc.inc, timezones.inc, Z-Merge, webodf, script.aculo.us and JSJaC. These libraries etc. would need to be unbundled to match the Fedora packaging guidelines [13], however some of the bundled components seem to be older versions and/or forked. All of these points are not new, mentioned publically [14] and also sent to the upstream developers about 2 years ago. - Zarafa 7.2 requires gSOAP >= 2.8.19 [15] which is currently satisfied by Fedora 22 and later. It is not impossible to update gSOAP on all relevant branches however there is at least an ABI incompatibility (with a soname version bump) between 2.8.17 and 2.8.21 (which simply means that then during the rebase of gSOAP in existing stable branches all other packages depending on gSOAP would have to be rebuilt against the new gSOAP version as well). Unbundling the gSOAP is needed according to Fedora packaging guidelines [13]. - New search-plus of Zarafa 7.2 also bundles at least python-magic [13].
I am really sorry for all Zarafa users at Fedora and EPEL which have to act now in one or the other way, but my lack of interest in Zarafa has multiple reasons. It took me about 12 months to get Zarafa into Fedora, I maintained Zarafa in Fedora with usually the latest version for about 5 years. But I'm not a fan of the Zarafa WebApp which replaces the Zarafa WebAccess sooner or later completely. Given the WebApp isn't a tiny piece of software, I am neither confident nor interested to maintain a software that I do not use. I would be happy if somebody else steps up and does the nice amount of work and continues with Zarafa in Fedora and EPEL.
References/links: [1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#End_of_Life_.28EOL.... [2] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_relea... [3] https://admin.fedoraproject.org/pkgdb/package/zarafa/timeline [4] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.10-ssl_protoco... [5] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.9-ssl_ecdhe.pa... [6] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/?h=f21 [7] http://www.zarafa.com/faq-about-zarafas-new-direction/7 [8] https://wiki.debian.org/Groupware/Giraffe [9] https://bugs.mageia.org/show_bug.cgi?id=14993#c3 [10] http://pkgs.fedoraproject.org/cgit/zarafa.git/diff/zarafa-7.1.4-libvmime092.... [11] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_support_def... [12] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_relea... [13] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [14] https://lists.fedoraproject.org/pipermail/zarafa/2013-September/000065.html [15] https://forums.zarafa.com/showthread.php?11043-gsoap-installation-not-checke...
Greetings, Robert
zarafa-announce@lists.fedoraproject.org