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 :)
Hi Andrea, thanks for your feedback, and you are fully right in principle, either a compatibility package should be provided, or that upgrade should not reach the stable repository. I just removed the auto-push feature. So, that package will reach the stable repository only if all the parties involved actually want it.
Note that in practice, there is a single package (outside of my own packages) depending on SOCI, namely fts, your package:
dnf repoquery -s --releasever=7 --whatrequires libsoci\* --disablerepo=* --enablerepo=epel --enablerepo=base | sort -u ... fts-3.8.4-2.el7.src.rpm
As I have recently built SOCI for EPEL 8, using the opportunity that SOCI 4.0.0-RCx has just been released (it is not so often that upstream make a release at all), I thought that this new version could be beneficial to EPEL 7 too. But I cannot spend too much time on it either. Normally, just a rebuild is necessary (soci-4.0.0 is already in the buildroot; so, launching a Koji/fedpkg build of your package should be enough). If you want, I can do it for you.
So, the easiest and quickest option would be to launch a rebuild of your package (fts), and if you are fine with the result, soci-4.0.0 can reach the stable repository on EPEL 7 when it is stable enough (in 12 days or something). But if you do not want, and prefer to stick to soci-3.2, then no problem, I'll cancel soci-4.0.0 on EPEL 7.