[perfsonar-user] postgresql9.5 dependency in perfsonar & obsolete packages

[Gerald Vogt]

Hi!

As postgresql 9.5 is now end-of-life I have been cleaning up and found
it installed on our perfsonar server. The 9.5 server isn't running but
the 10 instead, so it's not so big a deal, but I cannot remove the old
perfsonar95 rpms because of dependencies:

---> Package postgresql95-server.x86_64 0:9.5.3-2PGDG.rhel7 will be erased
--> Processing Dependency: postgresql95-server for package:
postgresql-load-1.1-1.el7.noarch
...
---> Package postgresql-load.noarch 0:1.1-1.el7 will be erased
--> Processing Dependency: postgresql-load for package:
pscheduler-server-4.3.4-1.el7.noarch
...
---> Package pscheduler-server.noarch 0:4.3.4-1.el7 will be erased
...
---> Package perfsonar-core.noarch 0:4.3.4-1.el7 will be erased
...

So basically it removes the whole pscheduler-server and perfsonar
because of the dependencies to postgresql-load.noarch which depends on
postgresql95. I guess, postgresql-load.noarch should not depend on a
specific postgresql server version?

I also checked with "yum autoremove" and it lists a number of obsolete
packages:

perl-Net-Netmask noarch 1.9015-13.el7 @epel7-centos7-x86_
postgresql95-contrib x86_64 9.5.3-2PGDG.rhel7 @perfSONAR
postgresql95-devel x86_64 9.5.3-2PGDG.rhel7 @perfSONAR
postgresql95-plpython x86_64 9.5.3-2PGDG.rhel7 @perfSONAR
python-daemon noarch 1.6-4.el7 @epel7-centos7-x86_64
python-flask noarch 1:0.10.1-5.el7_7 @centos7-x86_64-extras
python-html5lib noarch 1:0.999-7.el7 @ORG_epel7_epel_x86_64
python-icmperror noarch 0.1-1.el7 @perfSONAR
python-jsontemplate x86_64 0.87-1.el7 @perfSONAR
python-kafka noarch 1.4.6-1.el7 @perfSONAR
python-memcached noarch 1.48-4.el7 @centos7-x86_64
python-pscheduler noarch 4.2.4-1.el7 @perfSONAR
python-virtualenv noarch 15.1.0-4.el7_7 @centos7-x86_64-updates
python2-mock noarch 1.0.1-10.el7 @epel7-centos7-x86_64
samba-libs x86_64 4.10.16-13.el7_9
@ORG_centos7_updates_x86_64
Removing for dependencies:
pyldb x86_64 1.5.4-2.el7 @ORG_centos7_updates_x86_64
pytalloc x86_64 2.1.16-1.el7 @centos7-x86_64
python-babel noarch 0.9.6-8.el7 @centos7-x86_64
python-devel x86_64 2.7.5-90.el7 @ORG_centos7_updates_x86_64
python-functools32 noarch 3.2.3_2-1.el7 @perfSONAR
python-ipaddr noarch 2.1.11-2.el7 @centos7-x86_64
python-isodate noarch 0.5.4-8.el7 @centos7-x86_64
python-itsdangerous noarch 0.23-2.el7 @extras
python-jinja2 noarch 2.7.2-4.el7 @centos7-x86_64
python-markupsafe x86_64 0.11-10.el7 @centos7-x86_64
python-ntplib noarch 0.3.3-1.el7 @perfSONAR
python-psycopg2 x86_64 2.6.1-1.rhel7 @perfSONAR
python-py-radix x86_64 0.9.6-1.el7 @perfSONAR
python-pyjq x86_64 2.3.0-3.el7 @perfSONAR
python-subprocess32 x86_64 3.2.7-1.el7 @perfSONAR
python-tdb x86_64 1.3.18-1.el7 @centos7-x86_64
python-tzlocal noarch 1.2.2-1.el7 @perfSONAR
python-werkzeug noarch 0.9.1-2.el7 @extras
python2-attrs noarch 17.4.0-4.el7 @epel7-centos7-x86_64
python2-jsonschema x86_64 3.0.1-1.el7 @perfSONAR
python2-pyrsistent x86_64 0.14.11-1.el7 @perfSONAR
python2-rpm-macros noarch 3-34.el7 @ORG_centos7_base_x86_64


Are those really obsolete or are they not listed properly in other rpms
depending on them?

Thanks,

Gerald

[Mark Feit]

Gerald Vogt writes:

… I cannot remove the old perfsonar95 rpms because of dependencies:

---> Package postgresql95-server.x86_64 0:9.5.3-2PGDG.rhel7 will be erased
postgresql-load-1.1-1.el7.noarch
pscheduler-server-4.3.4-1.el7.noarch
…
So basically it removes the whole pscheduler-server and perfsonar
because of the dependencies to postgresql-load.noarch which depends on
postgresql95. I guess, postgresql-load.noarch should not depend on a
specific postgresql server version?

The version of postgresql-load you have installed depends only on PostgreSQL 10, so that shouldn’t be the cause. The naming of the packages specifically as posrgresql95-* is a quirk of how it was packaged by PGDG and Red Hat. I’d be interested to see what “rpm -q whatrequires postgresql95-server” yields. There shouldn’t be anything left on the system that requires it.

I also checked with "yum autoremove" and it lists a number of obsolete
packages:

perl-Net-Netmask noarch 1.9015-13.el7 @epel7-centos7-x86_

There was a historical requirement for that package that no longer exists.

postgresql95-contrib x86_64 9.5.3-2PGDG.rhel7 @perfSONAR
postgresql95-devel x86_64 9.5.3-2PGDG.rhel7 @perfSONAR
postgresql95-plpython x86_64 9.5.3-2PGDG.rhel7 @perfSONAR

Those were dependencies prior to 4.3. As mentioned above, all of postgresql95 should go with it.

python-daemon noarch 1.6-4.el7 @epel7-centos7-x86_64
…
Are those really obsolete or are they not listed properly in other rpms
depending on them?

All of the python-* packages are holdovers from Python 2, which we no longer use. Red Hat went through the same naming weirdness with the Python 2-to-3 transition that it did during the 32-to-64-bit transition. Basically, anything that’s python-* or python2-* is Python 2 and anything that’s Python3*-* is Python 3. The extra wildcard in the Python3 stuff has to do with inconsistency in the way Red Hat named packages between EL7 and EPEL.

Some of the systems in our test bed get rebuilt from scratch regularly, so missing dependencies would stand out like a sore thumb.

--Mark

[Gerald Vogt]

Post by Gerald Vogt
---> Package postgresql95-server.x86_64 0:9.5.3-2PGDG.rhel7 will be erased
postgresql-load-1.1-1.el7.noarch
pscheduler-server-4.3.4-1.el7.noarch
…
So basically it removes the whole pscheduler-server and perfsonar
because of the dependencies to postgresql-load.noarch which depends on
postgresql95. I guess, postgresql-load.noarch should not depend on a
specific postgresql server version?
The version of postgresql-load you have installed depends only on
PostgreSQL 10, so that shouldn’t be the cause.  The naming of the

Well, it is. yum thinks so:

--> Processing Dependency: postgresql95-server for package:
postgresql-load-1.1-1.el7.noarch

rpm thinks so, too:

[***@perfsonar7 ~]# rpm -q -R postgresql-load
/bin/sh
postgresql95-server
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Post by Gerald Vogt
packages specifically as posrgresql95-* is a quirk of how it was
packaged by PGDG and Red Hat.  I’d be interested to see what “rpm -q
whatrequires postgresql95-server” yields.  There shouldn’t be anything
left on the system that requires it.

Not for me:

[***@perfsonar7 ~]# rpm -q --whatrequires postgresql95-server
postgresql-load-1.1-1.el7.noarch

Post by Gerald Vogt
I also checked with "yum autoremove" and it lists a number of obsolete
There was a historical requirement for that package that no longer exists.
Those were dependencies prior to 4.3.  As mentioned above, all of
postgresql95 should go with it.
  …
Are those really obsolete or are they not listed properly in other rpms
depending on them?
All of the python-* packages are holdovers from Python 2, which we no
longer use.  Red Hat went through the same naming weirdness with the
Python 2-to-3 transition that it did during the 32-to-64-bit
transition.  Basically, anything that’s python-* or python2-* is Python
2 and anything that’s Python3*-* is Python 3.  The extra wildcard in the
Python3 stuff has to do with inconsistency in the way Red Hat named
packages between EL7 and EPEL.
Some of the systems in our test bed get rebuilt from scratch regularly,
so missing dependencies would stand out like a sore thumb.

So it should be safe to do a "yum autoremove" and get rid of those packages?

Thanks,

Gerald

[Gerald Vogt]

Post by Gerald Vogt

Post by Gerald Vogt
---> Package postgresql95-server.x86_64 0:9.5.3-2PGDG.rhel7 will be erased
postgresql-load-1.1-1.el7.noarch
pscheduler-server-4.3.4-1.el7.noarch
…
So basically it removes the whole pscheduler-server and perfsonar
because of the dependencies to postgresql-load.noarch which depends on
postgresql95. I guess, postgresql-load.noarch should not depend on a
specific postgresql server version?
The version of postgresql-load you have installed depends only on
PostgreSQL 10, so that shouldn’t be the cause.  The naming of the

postgresql-load-1.1-1.el7.noarch

It seems postgresql-load has been updated at some point without
increasing the version number. Here is when I have installed the rpm in
2020:

Mar 09 09:38:40 Installed: postgresql-load-1.1-1.el7.noarch

postgresql10 came much later:

Nov 03 06:28:46 Installed: postgresql10-libs-10.13-1PGDG.el7.x86_64

-Gerald

[Mark Feit]

Post by Gerald Vogt

Post by Mark Feit
The version of postgresql-load you have installed depends only on
PostgreSQL 10, so that shouldn’t be the cause. The naming of the

postgresql-load-1.1-1.el7.noarch

It seems postgresql-load has been updated at some point without
increasing the version number.

Think I found it. The code in postgresql-load didn’t change between releases, so the version number stayed the same. The packaging did and I neglected to update the release number. What we should have shipped was 1.1-2. Because of that, the RPM didn’t upgrade after the last release and the old dependency is still in place.

The next release will be 1.2-1 and will solve the problem. If you want to force things to clean up properly, a “yum reinstall postgresql-load” should bring the dependency up to the right version.

--Mark