> -----Ursprüngliche Nachricht----- > Von: Magnus Hagander <magnus@xxxxxxxxxxxx> > Gesendet: Freitag, 20. November 2020 16:29 > An: Zwettler Markus (OIZ) <Markus.Zwettler@xxxxxxxxxx> > Cc: pgsql-general@xxxxxxxxxxxxxxxxxxxx > Betreff: Re: Linux package upgrade without dependency conflicts > > On Thu, Nov 19, 2020 at 2:50 PM Zwettler Markus (OIZ) > <Markus.Zwettler@xxxxxxxxxx> wrote: > > > > We run Postgres 9.6 + 12 Community Edition on RHEL7 which we install directly > out of the PGDG channels using RPMs. We also run Patroni installed with RPMs > provided by Github. > > > > > > > > Currently we have major dependency conflicts with each quarterly Linux package > upgrade (yum upgrade), especially on PostGIS and Patroni. > > > > > > > > I was told that there will be no dependency conflicts anymore when we install > Postgres from sourcecode and Patroni with pip. > > > > > > > > Is that correct? Because all Linux packages required by Postgres will continue to > be updated. > > This is not really a PostgreSQL question, it's more of a RedHat question I'd say. > > In general, no. If you install from source you will have a different kind of > dependency management, and you need to handle all of that manually. As long as > you do, there shouldn't be issues. > > That said, what are your dependency conflicts? As long as you're using the PGDG > repositories on RHEL7 it should work without that. There have been some issues > with PostGIS on RHEL8, but I think they are mostly fine on RHEL7. But if you don't > actually show us what your dependency problems are, we can't tell you how to fix > it... > > (And why not use Patroni from the PDGD repositories?) > > > -- > Magnus Hagander > Me: https://www.hagander.net/ > Work: https://www.redpill-linpro.com/ The last problems I remember had been related to Patroni + python-psycopg and PostGIS + pgrouting_96. We used Patroni before it had been provided by the PGDG repositories. I am actually planning to use the RPMs from the PGDG repo in the future. I will post our actual problems the next time. Thanks, Markus