Bug 1718201

Summary: conflicts between "postgresql" module and PGDG repo packages
Product: Red Hat Enterprise Linux 8 Reporter: ioguix
Component: dnfAssignee: Jaroslav Mracek <jmracek>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: unspecified    
Version: 8.0CC: james.antill, jberan, pmoravec
Target Milestone: rc   
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-11 08:32:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description ioguix 2019-06-07 08:47:51 UTC
yum/dnf refuse to find/install many packages from PGDG repository on RHEL8

After installing the PGDG repository from yum.postgresql.org on RHEL8, I expect the following command to install PostgreSQL 11 and its dependencies:

  [root@localhost ~]# yum install postgresql11 postgresql11-server \
    postgresql11-contrib
  Updating Subscription Management repositories. 
  Last metadata expiration check: 0:00:49 ago on Fri May 17 16:33:48 2019.
  No match for argument: postgresql11 
  No match for argument: postgresql11-server 
  No match for argument: postgresql11-contrib 
  Error: Unable to find a match 

The package exists from the repository, eg:

  [root@localhost ~]# yum --quiet repoquery --repo pgdg11 postgresql11-server*
  postgresql11-server-0:11.2-2PGDG.rhel8.x86_64
  postgresql11-server-0:11.3-1PGDG.rhel8.x86_64

Even searching for the package doesn't work:

  [root@localhost ~]# yum search postgresql11-server
  Updating Subscription Management repositories.
  Last metadata expiration check: 0:23:08 ago on Fri May 17 00:23:20 2019.
  No matches found.

A workaround to this issue is currently to disable the "postgresql" module from appstream:

  [root@localhost ~]# yum -qy module enable postgresql
  [root@localhost ~]# yum -q info postgresql11-server|grep ^Name
  Error: No matching Packages to list
  [root@localhost ~]# yum -qy module disable postgresql
  [root@localhost ~]# yum -q info postgresql11-server|grep ^Name
  Name         : postgresql11-server

The only dependency who match a package in appsteam is on "libpq.so.5". This lib provided by package "postgresql11-libs" from the PGDG repo.

Behavior is quite surprising. I suppose the package manager should provide a better error message /advice if there is some conflicts or dependency issues or if it is not able to make a choice between two packages.

Moreover, is it something to be fixed on "postgresql" module side or in PGDG repo side? How?

Thanks,

Comment 1 Jaroslav Mracek 2019-06-11 08:32:56 UTC
I believe that you experience of consequence of modular filtering (not a bug). Please see https://github.com/rpm-software-management/dnf/blob/master/doc/modularity.rst.

When module postgresql is enabled or default, all packages that has the same name with modular packages are excluded from all repositories. To disable modular filtering for certain repository, just add "module_hotfixes=true" into
 corresponding .repo file in /etc/yum.repos.d/.

Hope that it helps.

Comment 2 ioguix 2019-06-11 20:02:58 UTC
Interesting!

Thank you for the pointer. It works as expected. I'm not sure what package name they have in common though, as wall packages in PGDG repo avec suffixed with the major version, eg: postgresql11, postgresql11-server, etc. But anyway.

I supposed the best approach would be to add modules in the pgdg repository itself. It sounds the perfect fit to provide all supported PostgreSQL major version from one repo (PGDG provide one repo per version today). However, what happen when two repo provide same module name?

Thanks again anyway!

Comment 3 ioguix 2019-06-11 20:07:10 UTC
One additional note though. I suppose this modular filtering should appears somewhere as a warning or at least as a debug message.

Today, this is just black hole pretty hard to detect for newcomers in RHEL8 and/or modules and streams :/