Error when Installing Some Postgresql Packages (Perl IPC-Run)

Resolving PostgreSQL 17 Dependency Error on Oracle Linux 8

Fixing perl(IPC::Run) Dependency Error When Installing PostgreSQL 17 on Oracle Linux 8

Background

While preparing a fresh Oracle Linux 8 server for a PostgreSQL 17 deployment, an attempt to install all PostgreSQL packages in one go failed with an unsatisfied dependency error:

Problem 1: cannot install the best candidate for the job
- nothing provides perl(IPC::Run) needed by postgresql17-devel-17.4-1PGDG.rhel8.x86_64
...

Root Cause

The perl(IPC::Run) module (along with several tool‑chain libraries) resides in the CodeReady Builder repository, which is disabled by default on Oracle Linux 8. Because postgresql17-devel and postgresql17-test depend on that module, dnf/yum cannot resolve the full dependency tree unless the repository is enabled.

CodeReady Builder hosts developer‑oriented packages—compilers, debuggers, Perl/Python modules—that many “‑devel” RPMs rely on.

Solution

  1. Enable the CodeReady Builder repository:

    sudo dnf config-manager --enable ol8_codeready_builder

  2. Rerun the installation command:

    sudo yum install postgresql17*

With the additional channel enabled, dnf successfully pulled in perl(IPC::Run) and the entire PostgreSQL 17 toolchain (devel, contrib, docs, plperl, plpython, etc.) installed without further issues.

Verification & Post‑Install Tasks

Confirm package presence:

rpm -qa | grep ^postgresql17

Initialize and start the database cluster:

sudo /usr/pgsql-17/bin/postgresql-17-setup initdb
sudo systemctl enable --now postgresql-17

Key Takeaways

  • Developer packages frequently depend on CodeReady Builder content.
  • Check repository status with dnf repolist all before large installs.
  • Use --enablerepo for one‑off operations if you prefer not to keep CodeReady Builder enabled permanently.

Comments

Post a Comment

Popular posts from this blog

Creating Jobs With Different Users via pg_cron in Azure Postgresql Flexible Server

PostgreSQL pg_cron: Scheduling Materialized View Refresh Across Databases PostgreSQL pg_cron: Scheduling Materialized View Refresh Across Databases In this tutorial, I’ll walk you through the process of scheduling a Materialized View refresh using the pg_cron extension in PostgreSQL. Specifically, we’ll cover how to execute a scheduled SQL command in a different database using cron.schedule_in_database . Step 1: Enable the pg_cron Extension in Azure Portal On Azure PostgreSQL Flexible Server, the pg_cron extension is managed directly through the Azure portal. Follow these steps: Go to the Azure portal and navigate to your PostgreSQL Flexible Server instance. Under the Server Parameters section, locate the azure.extensions parameter. Add PG_CRON to the list of allowed extensions (as shown in the screenshot). Once enabled, the extension is automatically installed in the default `postgres` database . If you need to schedule jobs in o...
Read more

Oracle 19c Dataguard Installation with DG Broker

Oracle 19c Data Guard – Standby Creation, Switchover & Failover Oracle 19c Physical Standby Creation & Management (RMAN Duplicate + Data Guard Broker) This article walks through building a physical standby using RMAN  DUPLICATE FROM ACTIVE DATABASE , then managing switchover / failover with the Data Guard Broker. The commands were tested on Oracle Linux 8 with Oracle Database 19c . Assumptions Two hosts ( oracle1.localdomain & oracle2.localdomain ) with Oracle 19c installed. Primary instance runs on oracle1 ; standby will be created on oracle2 . Listener port 1521 is reachable in both directions (check firewalls). Primary DB name MYDBPROD ; standby unique name MYDBDG . 1 – Primary Server Preparation 1.1 Switch to ARCHIVELOG & Force Logging -- Check mode SELECT log_mode FROM v$database; -- If NOARCHIVELOG: SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCH...
Read more