* Require libxslt and docbook-dtds for building documentation
* Require clang and llvm for building JIT bitcode
* Package JIT bitcode in llvmjit subpackage
* Drop devel subpackage as upstream no longer installs liblwgeom
* Fix various issues with shared object names and versions
* Strip -fstack-clash-protection from compiler flags for clang
The binaries (from previous_prefix/bin directory) only generated
additional implicit Requires, which complicated dependency
resolution.
Also confess that the postgis-upgrade actually bundles postgis of
previous version.
Related: rhbz#1055293
Version: 2.4.1-2
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
Next time I should use:
$ koji wait-repo --build NVR --target fNN-build
or:
$ koji wait-repo --build NVR --target rawhide
Instead of:
$ koji wait-repo --build NVR rawhide
Sorry for rush.
Version: 2.3.0-3
