Future of Zarafa in Fedora and EPEL
by Robert Scheck
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_.28E...
[2] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_re...
[3] https://admin.fedoraproject.org/pkgdb/package/zarafa/timeline
[4] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.10-ssl_prot...
[5] http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.9-ssl_ecdhe...
[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-libvmime0...
[11] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_support_...
[12] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_re...
[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-che...
Greetings,
Robert
--
Fedora Project * Fedora Ambassador * Fedora Mentor * Fedora Packager
8 years, 2 months
- 1
- 0
- ← Newer
- 1
- Older →