3

Background

I'm planning to set up a PostgreSQL/PostGIS server on RHEL 9.4 as part of migration work from an older version of RHEL and am comparing upgrade paths from a stability perspective.

If I understand correctly, there are two ways to install PostgreSQL and PostGIS on RHEL9:

Option 1: Use the PostgreSQL repository

Install both PostgreSQL (postgresqlNN-server) and PostGIS (postgisNN_MM) from the official PostgreSQL repository (pgdgNN).

This option follows the maintenance cycle of PostgreSQL and PostGIS.

Option 2: Use the RHEL9 and EPEL repositories

Install PostgreSQL (postgresql) from Red Hat Application Streams and PostGIS (postgis) from EPEL.

Red Hat provides multiple versions of PostgreSQL:

For PostGIS, upgrades are provided by EPEL on a best-effort basis due to the community-driven nature of the project. That said, EPEL maintainers strive to maintain packages until the RHEL EOL.

From the EPEL FAQ:

How long are EPEL packages updated?

Ideally, EPEL packages are maintained as long as the corresponding RHEL release is supported. However, EPEL is a volunteer effort, and a package maintainer can retire their EPEL branch at any time.

Question

I'm considering using EPEL PostGIS because it complements Red Hat-provided PostgreSQL, which offers a long lifecycle (PostgreSQL 13 supported until 2032). However, I'm concerned about the long-term compatibility of EPEL packages with Red Hat-provided software, especially after upstream versions (e.g., PostgreSQL or PostGIS) reach EOL.

In my case, the upstream PostgreSQL will reach EOL in 2025-11, and looking at the PostgreSQL-PostGIS compatibility chart and extrapolating the trend, I expect that PostGIS will drop support for PostgreSQL 13 in upcoming releases.

How are EPEL packages like PostGIS typically maintained in such scenarios, especially when tied to Red Hat-provided software with a longer lifecycle?

Specifically:

  • Will the EPEL version of PostGIS continue to receive updates to remain compatible with PostgreSQL 13 until RHEL9's EOL?
  • Is there precedent or standard practice for EPEL packages to backport changes from upstream versions in cases like this?
Yuki Sasaki
  • 133

1 Answers1

3

In a word, no. EPEL is a volunteer effort. There is no guarantee a given major version will be packaged, especially for the full duration while upstream changes.

This is a typical upstream or downstream choice. Your downstream distro, RHEL + EPEL, has what you want now, built according to their preferences. However the current version of PostGIS will be end of life before RHEL is, even with the helpful upstream end of life policy.

Consider upgrading RHEL, and PostgreSQL, faster than that. To RHEL 10 soon after release. Remind EPEL maintainers for an el10 build of PostGIS. At the end of this additional version jump, you will be much more recent and will enjoy support of all your software for a while.

I do not see evidence in the EPEL postgis package of maintaining patches not upstream, or accommodating multiple PostgreSQL versions. Either would be a large amount of work, to the extent that you would likely need to be involved as a EPEL maintainer to help make it happen.

Or, your other option of upstream packages exist. Advantage of your choice of PostgreSQL versions, including current. However third party software repos are a different software source to trust and follow, and do not always follow Fedora conventions about how things work. While PostgreSQL is an established community and this certainly could work, now you are relying on the upstream community for support, not Red Hat.

John Mahowald
  • 36,071