use_upstream_repo is unable to install the latest version of pg on Centos 7
bebosudo opened this issue · 4 comments
Hi,
I'm using this formula on a CentOS 7, when I try to install with use_upstream_repo, the postgresql-server state crashes due to a missing dependency unsatisfied.
This is my pillar configuration:
postgres:
use_upstream_repo: True
fromrepo: pgdg10
version: '10'
From the logs of the minion I was able to find the line submitted:
# systemd-run --scope yum -y --disablerepo=* --enablerepo=pgdg10 install postgresql10
Running scope as unit run-32266.scope.
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package postgresql10.x86_64 0:10.5-1PGDG.rhel7 will be installed
--> Processing Dependency: postgresql10-libs(x86-64) = 10.5-1PGDG.rhel7 for package: postgresql10-10.5-1PGDG.rhel7.x86_64
--> Processing Dependency: libicu for package: postgresql10-10.5-1PGDG.rhel7.x86_64
--> Processing Dependency: libpq.so.5()(64bit) for package: postgresql10-10.5-1PGDG.rhel7.x86_64
--> Running transaction check
---> Package postgresql10.x86_64 0:10.5-1PGDG.rhel7 will be installed
--> Processing Dependency: libicu for package: postgresql10-10.5-1PGDG.rhel7.x86_64
---> Package postgresql10-libs.x86_64 0:10.5-1PGDG.rhel7 will be installed
--> Finished Dependency Resolution
Error: Package: postgresql10-10.5-1PGDG.rhel7.x86_64 (pgdg10)
Requires: libicu
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
which is the same error I see in the state stderr when it fails.
The problem is in that --disablerepo=*, because libicu is not provided by the pg upstream repo but is taken from base.
...
--> Processing Dependency: libicu for package: postgresql10-10.5-1PGDG.rhel7.x86_64
--> Processing Dependency: libpq.so.5()(64bit) for package: postgresql10-10.5-1PGDG.rhel7.x86_64
--> Running transaction check
---> Package libicu.x86_64 0:50.1.2-15.el7 will be installed
...
============================================================================
Package Arch Version Repository Size
============================================================================
Installing:
postgresql10 x86_64 10.5-1PGDG.rhel7 pgdg10 1.6 M
Installing for dependencies:
libicu x86_64 50.1.2-15.el7 base 6.9 M
postgresql10-libs x86_64 10.5-1PGDG.rhel7 pgdg10 354 k
Transaction Summary
============================================================================
Install 1 Package (+2 Dependent packages)
After manually installing libicu the formula completed successfully.
By adding base to the fromrepo in pillar, it was able to install also libicu from the base repository.
postgres:
use_upstream_repo: True
fromrepo: pgdg10,base
version: '10'
I could add ,base to the fromrepo of the RedHat family:
Do you think this is the correct approach?
Same thing on a fresh install, I don't know enough about repo handling in RHEL to answer, but if it gives priority to the pgdg repos and then looks in base, this seems reasonnable. It works when set though pillar.
However, since the naming doesn't conflict, we could just drop fromrepo on RH-like distribs?
However, since the naming doesn't conflict, we could just drop fromrepo on RH-like distribs?
If you don't set the fromrepo: .. in your pillar, it will use line 42 from osfamilymap.yaml, which breaks the installation.
I think the fromrepo in the yaml should stay there as it is, since we want to install pg from the repo with the specific release we choose, but we need to either ask maintainers of the pg RPM repos to add libicu, or add ,base in this salt formuia for RedHat families (not a great idea, since people may disable/rename/remove the base repo from their servers), or at least make the users of this formula aware that they need to provide another repo in their pillars that provides libicu.
The best would be solution 1, otherwise 3.
I came across this issue today when provisioning a new machine. I think for the sake of making the formula usable for RedHat families we should add the ,base workaround until either solution 1 (which seems unlikely to me, it would not make sense for maintainers to ship a package that is already in the base repository) or 3 are implemented.
I applied the ,base fix in our fork and I can report that is works properly (just make sure to modify both client and server states as both of them require libicu), so anyone coming across this issue should be able to work around it.