Terje Røsten (FAS: terjeros) and I (FAS: music) have been
impact-checking an update of gtest to 1.17.1, as proposed by Zephyr
Lykos (FAS: mochaa)[1]. The gtest source package also provides the
gmock/gmock-devel binary RPMs.
Since gtest has no ABI compatibility guarantees and uses the full
version number as the ABI version, this will be an ABI-incompatible
update. Most packages that depend on gtest do so only as a test
dependency, so they will not need to be rebuilt, and only need API
compatibility to continue to build from source. I used the following
commands to look for packages with binary RPMs that actually link
libraries from gtest:
$ repoquery --repo=rawhide --whatrequires 'libgtest*.so.*'
$ repoquery --repo=rawhide --whatrequires 'libgmock*.so.*'
Based on these queries, the source packages that will need to be rebuilt
in the same side tag are only the following nine: abseil-cpp, cachelib,
davix, libcamera, mir, pkcs11test, python-steps, sdbus-cpp, and wlcs.
Maintainers of these packages should have received this email directly
by BCC. I intend to rebuild all nine packages in a side tag using either
(co-)maintainer status or provenpackager privilege.
However, there are many more source packages that BuildRequire gtest and
could be impacted by API changes:
$ fedrq wrsrc -s gtest | wc -l
175
This gtest update is particularly significant because gtest now requires
at least C++17. Several packages that were building as C++14 have needed
to be adjusted to build as C++17 instead. In general, Terje and I have
already taken care of submitting these PR’s and getting them merged,
getting consent from the package maintainers whenever we could. The
exceptions are those for spatialindex[2] and spatialindex2.0[3]. If
those are still awaiting review when I ship the gtest update, I will
merge them as provenpackager.
There are a couple of relevant PR’s opened by Terje that are still
pending. The folly package already FTBFS, but [4] would fix it, and the
package impact-checks successfully afterward. I do not plan to use
provenpackager privilege for this PR since we are not making the
situation worse, and there may be a better approach than skipping these
tests. The root package would have a couple of new test failures with
gtest 1.17.0; we haven’t tried to investigate exactly what is going
wrong, but [5] would skip the affected tests. I am not sure if that is
the approach that the root maintainers want to take, so I won’t merge
the PR without maintainer feedback. Plus, we haven’t quite proven that
these aren’t simply COPR-specific failures rather than ones due to the
gtest update. If no action is taken, root may start to FTBFS (but not
FTI!) after the gtest update.
Looking at Terje’s original COPR impact check[6] and at an updated one I
just conducted[7][8], it looks like there should not be any other
impacts from the gtest update. We plan to proceed in one week, on
2025-11-11, or slightly later. Thanks to Terje and Zephyr for working so
hard on this update and for taking the time to understand its effects.
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/gtest/pull-request/9
[2] https://src.fedoraproject.org/rpms/spatialindex/pull-request/4
[3] https://src.fedoraproject.org/rpms/spatialindex2.0/pull-request/1
[4] https://src.fedoraproject.org/rpms/folly/pull-request/34
[5] https://src.fedoraproject.org/rpms/root/pull-request/7
[6] https://copr.fedorainfracloud.org/coprs/terjeros/gtest-1.17.0/packages/
[7] https://copr.fedorainfracloud.org/coprs/music/gtest/packages/
[8] https://src.fedoraproject.org/rpms/gtest/pull-request/9#comment-289491
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
