UPDATE:
The proposed specfile change is even simpler than that.

Both cmake (fedora) and cmake3 (rhel 7) package define %ctest3 macro:

>[abauer@vFedora ~]$ rpm --eval %ctest3
>
>  cd "x86_64-redhat-linux-gnu" 
>  /usr/bin/ctest --output-on-failure --force-new-ctest-process -j4  
>  cd -


>[abauer@vCentOS7 ~]$ rpm --eval %ctest3
>
>  cd "." 
>  /usr/bin/ctest3 --output-on-failure --force-new-ctest-process -j4  
>  cd -

So, all we need to do is change:

ctest -> %{ctest3} under %check

FEDORA-EPEL-2021-d5fe34a16a has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d5fe34a16a

FEDORA-EPEL-2021-d5fe34a16a has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d5fe34a16a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2021-d5fe34a16a has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.

This update bumps the soname from libfmt.so.3 to libfmt.so.6.  This is a breaking change which is against EPEL Policy [0].  mkvtoolnix no longer installs and needs to be rebuilt against the new soname (bug 1931239). Why wasn't the Incompatible Upgrades Policy [1] followed?


[0] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy
[1] https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy

> This is a breaking change which is against EPEL Policy [0].

That's why I'm not touching EPEL.

> Why wasn't the Incompatible Upgrades Policy [1] followed?

EPEL 7 didn't previously have an FMT library. Please check which repo you got libfmt.so.3 from.

> EPEL 7 didn't previously have an FMT library. Please check which repo you got libfmt.so.3 from.

Yes it did, and that's where I installed it from.  I got it as a dependency of mkvtoolnix.  You can see in koji that mkvtoolnix-46.0.0-1.el7 was built against fmt-devel-3.0.2-1.el7 [0] and was linked against libfmt.so.3 [1].  You can also see the previous bodhi updates for EPEL7 [2], as well as the fact that the epel7 merge commit [3] has a parent commit updating the package to 3.0.2-1 [4].

So I ask again, why wasn't the Incompatible Upgrades Policy followed?  At a minimum, the submitter needs to email epel-devel to inform people of this situation.  I've already rebuilt mkvtoolnix against the new soname (bug 1931239), but anyone else linking against that library needs to be informed.


[0] https://kojipkgs.fedoraproject.org//packages/mkvtoolnix/46.0.0/1.el7/data/logs/x86_64/root.log
[1] https://koji.fedoraproject.org/koji/rpminfo?rpmID=21364654libfmt.so.7()(64bit)
[2] https://bodhi.fedoraproject.org/updates/?packages=fmt&release=epel-7
[3] https://src.fedoraproject.org/rpms/fmt/c/f49096bb0f571d532645483e73d988317c60da89?branch=epel7
[4] https://src.fedoraproject.org/rpms/fmt/c/15761facdfecf616c9a88c1b025d5b3b1f6e1f53?branch=epel7

> [1] https://koji.fedoraproject.org/koji/rpminfo?rpmID=21364654libfmt.so.7()(64bit)

Please excuse the typo, this link should be https://koji.fedoraproject.org/koji/rpminfo?rpmID=21364654

Kefu, please send an email to epel-devel to inform people about this incompatible upgrade.

Vitaly, since Kefu is not responding will you handle announcing this on epel-devel?

Sorry, I'm not interested in EPEL7.

hi Carl, sorry for

1) missing the needinfo. somehow, i didn't get the notification.
2) violating the policy. i didn't mean to do so. just forgot to check for packages depending on libfmt and to send the mail to the ML.
3) introducing the regression and the inconvenience.

i just sent a mail to the epel-devel ML.

hi Vitaly, i am sorry for the noise.