MongoDB on Fedora - Business case for MongoDB support

I know what the policy is on Fedora and why MongoDB 5 is hard to install on Fedora.
It appears it would be pretty trivial for the team to fix the issues with Fedora installs.
The business case for such support, aside from the perennial issue of mindshare, is that a lot of us who plan to deploy on RedHat do our development on Fedora to save money :slight_smile:

Hi @Jack_Woehr,

Major releases in Fedora and similar distros are generally too short-lived for the MongoDB server packaging, testing, and support schedule. For example, the Fedora Release Life Cycle ships a new version about every 6 months with a roughly 13 month maintenance window.

MongoDB ships a major production server release series about once a year followed by 30 months of maintenance and security updates (see: MongoDB Software Support Policies). This release cadence aligns much better with releases that have LTS (Long Term Support) life cycles like RHEL and Ubuntu Server LTS.

LTS releases typically have at least 5 years of full support for maintenance support and often have options to extend support 10+ years from the original release date. Short-lived or continuous releases (eg CentOS Stream) have more frequent changes in kernels and library dependencies that make packaging and testing binary packages much more difficult. The mismatch in lifecycles also means a short-lived O/S release will be unsupported upstream for a good percentage of a MongoDB server release’s support lifecycle.

Since your goal is to optimise costs but support a business case of deploying on RHEL, I recommend choosing one of the freely available RHEL derivatives that closely tracks the upstream Redhat releases.

Fedora development tracks ahead of RHEL and will include newer versions of kernels and libraries that may not be representative of what to expect when you deploy on RHEL.

Before Redhat discontinued stable CentOS releases tracking RHEL, CentOS would have been the recommended path for an open source Linux distro compatible with RHEL. There are several new projects aiming to fill the RHEL-compatible release role, like Rocky Linux and AlmaLinux.

However, since it is perhaps easier to change your deployment approach than your preferred O/S there are some other options to consider:


1 Like

@Stennie , thanks for the finely detailed response!

A Linux user since 1994, I had not heard of the Rocky or Alma distros :slight_smile: Always something new to learn!

I’ll probably go with the “build from source” option since that’s the Fabled Land from whence I came :slight_smile:

Hmm, well, that not terribly successful.

g++ -o build/opt/third_party/boost/libs/thread/src/pthread/thread.o -c -Woverloaded-virtual -Wpessimizing-move -Wno-maybe-uninitialized -fsized-deallocation -std=c++17 -Wno-overloaded-v
irtual -Werror -fasynchronous-unwind-tables -ggdb -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -fno-omit-frame-pointer -fno-strict-aliasing -O2 -march=sandybridge -mtune=gene
ric -mprefer-vector-width=128 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -Wno-missing-braces -f
stack-protector-strong -Wa,--nocompress-debug-sections -fno-builtin-memcmp -fPIE -DPCRE_STATIC -DNDEBUG -D_XOPEN_SOURCE=700 -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -DBOOST_THREAD_VERSION=5 -D
In file included from src/third_party/boost/boost/thread/thread_only.hpp:17,
             from src/third_party/boost/libs/thread/src/pthread/thread.cpp:11:
src/third_party/boost/boost/thread/pthread/thread_data.hpp: In member function 'void boost::thread_attributes::set_stack_size(std::size_t)':
src/third_party/boost/boost/thread/pthread/thread_data.hpp:61:19: error: comparison of integer expressions of different signedness: 'std::size_t' {aka 'long unsigned int'} and 'long int' [-Werror=sign-compare]
   61 |           if (size<PTHREAD_STACK_MIN) size=PTHREAD_STACK_MIN;
  |                   ^

… and then …

cc1plus: all warnings being treated as errors
scons: *** [build/opt/third_party/boost/libs/thread/src/pthread/thread.o] Error 1
scons: building terminated because of errors.
build/opt/third_party/boost/libs/thread/src/pthread/thread.o failed: Error 1

Also @Stennie the GitHub page sez:

Technical questions about building and developing MongoDB:

But that’s a private forum.

Hi Jack,

Both of those Linux distros were created in response to Redhat deciding to discontinue stable CentOS releases in Dec 2020 and focus on CentOS Stream (which has rolling releases instead of tracking RHEL releases). There is strong community motivation to have a RHEL-compatible open source distro, which is the role formerly filled by CentOS.

Borrowing descriptions from their respective project sites:

Rocky Linux is a community enterprise operating system designed to be 100% bug-for-bug compatible with America’s top enterprise Linux distribution now that its downstream partner has shifted direction. It is under intensive development by the community. Rocky Linux is led by Gregory Kurtzer, founder of the CentOS project.

AlmaLinux OS is an open-source, community-driven Linux operating system that fills the gap left by the discontinuation of the CentOS Linux stable release. AlmaLinux OS is a 1:1 binary compatible fork of RHEL® guided and built by the community.

As a standalone, completely free OS, AlmaLinux OS enjoys $1M in annual sponsorship from CloudLinux Inc and support from other sponsors. Ongoing development efforts are governed by the members of the community.

Actually, there was a missing redirect that I corrected.


Thanks for fixing that.

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.