I was able to install that package (cmake3 v3.17), admittedly first removing the RHEL cmake one.
Newer versions of cmake (v3.15+) are really needed.
While I fully understand why the ABI of runtime libraries must not be upgraded/bumped during the lifetime of a LTS (Long Term Supported) distribution, I am less convinced of the rationale of keeping build tools like cmake well behind. Users of the distributions are not negatively impacted by upgrades of build tools such as cmake. On the contrary, the users of build tools are by design developers (C/C++ developers in the case of CMake), and keeping the build tools outdated just add on the burden to maintain packages, obliging us to constantly backport bug fixes on both the upstream packages and on the build tools themselves. Maintaining my own packages with cmake 3.11 on EPEL is practically impossible, now that upstream has realized the benefit of CMake v3.15+, especially when it comes to support of Python 3 and latest Boost libraries: the CMake support files have been drastically re-worked and no longer compatible with older versions of CMake, including cmake 3.11.
So, if CMake is not upgraded on EPEL, I will have to abandon the maintenance of most of my own packages there. Hopefully we will find a solution. Let's be it if it is with modules, fair enough. I would then be grateful if someone be kind enough to explain how to make use of it once the new CMake modules are properly cooked :)
Will you make it available on EPEL 8 too?
Appstream repositories already provide
Yes, I know. But
CMake-3.11 is too old for some of the packages I would like to have on CentOS 8, especially with respect to the support of Python 3 and Boost.Python.
For instance, without more recent CMake versions, it is really tricky to have consistent versions of Python libraries and Boost.Python. Right now, to build those (not yet in EPEL) packages (e.g., in Docker images), I have to bundle the CMake binary; I would rather install CMake from the standard EPEL repository.
Again, you are right in principle. However, in that case, all the packages depending on SOCI are mine, and (whether it is unfortunate or not, I am not sure though) I am the sole user of those. I know because I am also the upstream owner. So, the only person who will have an issue with that update is me, and that is the main reason why I did not want to kind of over-engineer it with the chained build.
Thanks for your kind words!
If you find any issue, then please speak up so that I can stop this update to reach the stable repository. As a matter of fact, technically speaking your package is not the only one to use SOCI; there are at least 10 other packages depending on SOCI... but they are all mines! That is why I packaged SOCI in the first place :)
Since SOCI was getting old (there has not been any release for at least the last 5 years), when building Docker images for instance, I had to release SOCI manually in /opt from the Git master branch, which was pretty bad for reproducibility/maintenance (on CentOS 7, it was fine though). Now that they eventually release the very long-awaited 4.0.0 version, I take that opportunity to replace all those custom builds by properly packaged SOCI. And there is no reason that CentOS 7 should not enjoy the upgrade too :)