I have published before the FreeSWITCH 1.10.2 RPM's for CentOS 6 (x86_64 only), 7 and 8. I am very proud to share with you all the FreeSWITCH 1.10.3 RPM's for CentOS.
These RPM's are quite different than the originals from the FreeSWITCH team. The outstanding features of these RPM's are:
- SMS Flowroute module (mod_sms_flowroute) is now enabled and packed.
- Video enabled, h26x and VPx are packed. I had trouble packing VLC, so, for now, mod_vlc won't be available.
- Linked against tmalloc, as my readings (google it please), tmalloc seems to be the fastest memory library.
- Python enabled, mod_python is packed. Please note that CentOS 8 uses Python 3 and 2 at the same time. FreeSWITCH uses python 2. You may need to use the alternative command to have backwards compatibility. I am not a Python coder myself.
- MariaDB enabled: mod_mariadb is packed. This was a big deal. I will explain why below.
RPM's are available for CentOS 6, 7 and 8. And you can find it if you type yum search freeswitch.
As I said, there are more than 2200 working hours so far in order to make this possible.
CentOS 6 Notes
The following warnings apply for CentOS 6 users:
- Since 1.10.2, you require SQLite 3.7.x (the configure script still thinks the 3.6.20 release shipped with CentOS 6 is enough, but it will fail). I have ported it from CentOS 7; because SQLite is a core library, you will need to be careful if this backport doesn't have any side effects. Usually, you shouldn't as a VoIP server shouldn't have any other kind of software installed.
- EoL is close, according to my readings. When this happens, I will stop updating this repository as well. If someone of you wants to still use a CentOS 6 repo, contact me.
Why Packing for CentOS 8 was so Challenging?
There was more than one issue, most of them were as easy as repacking the old CentOS 7 SRPMS I have been doing or updating new RPM provides. However, the big issue. CentOS 8 is shipped with MariaDB 3:10.3.11 which means it has libmariadb 3.0.7. FreeSWITCH 1.10.x needs at least libmariadb 3.0.9 so, for starters, it cant not be used.
Then, I looked at the official MaríaDB RPM's. The issue here is that they do not have epoch in the versioning (missing epoch means zero). According to the RPM's versioning rules, 3:10.3.11 > 10.4.10, therefore, the RPM engine won't install it. I took a look into the SRPMS from MariaDB but they are not conventional, they are kind of an SRPMS inside another SRPMS. Even if I add the epoch information, when repacking it will get the same useless number. I kept looking for a day without success. Therefore, I couldn't use it.
Disabling the AppStream repository and enabling the MariaDB repository was not an option. The problem was that the AppStream repository has many dependencies within, including the GCC itself. I couldn't disabled right away.
Then I decided to do the impossible mission: to recompile all the needed SRPMS from CentOS 8 in order to be able to disable the AppStream package. It was not easy, it seems CentOS 8 repository planning has some faults:
- some lib*-devel packages were in the AppStream repository while library RPM was in the BaseOS repository, this reminds me of the horrible ClearOS distribution.
- some SRPMS had some BuildRequirements statements that were not available in CentOS 8. So, I looked at Fedora 28 (CentOS 8 is supposed to be based on Fedora 28) and if still not available I looked at Fedora 29 or 30. I wonder how CentOS people build some packages such as nodejs with some missing RPM's.
- the python doesn't exist anymore; in CentOS 8 it is python2 or python3 but not python. I couldn't use the alternative command because mock doesn't support it. So, all the SRPMS that had to do something with python had to be patched.
I repacked no less than 500 SRPM's, after that was done, disabling the AppStream repository was possible and the FreeSWITCH RPM build on CentOS 8 was possible.
UPDATE: I found a way to void packaging everything in the future. The RPM's will still be available but they will get updated when CentOS 8 publish new revisions.
Enjoy!blog comments powered by Disqus