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.

Wrt the libpd-devel dependency, a filtering macro was missing. It has been added in https://koji.fedoraproject.org/koji/taskinfo?taskID=39208447 Will create a new update for it. Thanks!

Thanks! As a matter of fact, all the packages depending on SOCI are mine. So, the update would be coordinated :)

For the dependency on libpq-devel and the Python sub-package name, you are (of course) righ; thanks for that report!

Thanks Andrea!

I guess that it would be better to create an issue upstream: https://github.com/SOCI/soci/issues It may be easier if you first install the debugging symbols (with something like sudo debuginfo-install soci-devel)

Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1770800

https://bugzilla.redhat.com/show_bug.cgi?id=1770858

https://bugzilla.redhat.com/show_bug.cgi?id=1770843

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 :)

Ok, a new update of fts has just been submitted, based on SOCI 4.0.0. So, all should be fine by now then.

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.

Kind regards

Denis

This update has been unpushed.

Thanks for the tests! Oops, my bad for the ABI breakage, sorry. I was too quick when I read the Bugzilla issues requiring an upgrade to newer version...

Thanks!

This update has been submitted for stable

This update has been submitted for stable

This update has been submitted for stable

This update has been submitted for stable

This update has been submitted for stable

This update has been submitted for testing