Usually (when only postgis is updated, and not postgresql itself)
it is enough to maintain only the latest version of
postgis-%majorversion.so file. The upgrade scenario is then hit
(a) 'dnf upgrade -y', which brings 'postgis-X.Y+1.so', and
(b) run (manually) 'ALTER EXTENSION potgis' for all the databases.
For this scenario the compatibility library is not needed at all.
The situation is complicated in situations where also PostgreSQL
has major version upgrade (when upgrading from Fedora N to Fedora
N+1, usually). Then, you need to *also* have
(a) 'postgis-%prevversion.so' built against old server (against
postgresql-upgrade-devel), and (b) 'postgis-%prevversion.so' built
against the actual postgresql version (postgresql-devel). The
first library is needed to allow the old-stack dump properly, and
the second is needed to satisfy pg_upgrade's pre-upgrade checks
(pg_upgrade is checking that the same library exists for both
stacks, in the same version). Note that it seems like *it could
be* enough to have just symlink from %majorversion to
%prevmajorversion posgis.so to "silence" the pg_upgrade's checker,
but I'm not brave enough to go this way at this point.
There's one more (maybe theoretical) possibility that the
PostgreSQL version is updated, but PostGIS version is not. In
this case, the prevmajorversion should be eqal to majorversion
(for the build against older stack), and the compat build
shouldn't be needed. If this ever happens, we can twak the
buildsystem/macros more.
Version: 2.4.0-1
Pavel Raiskup