Bug 2380898 - mingw-biblesync: FTBFS with change proposal CMake 4.0
Summary: mingw-biblesync: FTBFS with change proposal CMake 4.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mingw-biblesync
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: greg.hellings
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: CMake4.0
TreeView+ depends on / blocked
 
Reported: 2025-07-16 13:51 UTC by Cristian Le
Modified: 2025-07-19 16:56 UTC (History)
7 users (show)

Fixed In Version: mingw-biblesync-2.1.0-15.fc43
Clone Of:
Environment:
Last Closed: 2025-07-19 16:28:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Fedora Package Sources mingw-biblesync pull-request 2 0 None None None 2025-07-18 13:22:21 UTC

Description Cristian Le 2025-07-16 13:51:49 UTC
Dear package maintainer,

This is an automated bug created due to a FTBFS when rebuilding this package for the change proposal CMake 4.0.

The rebuild is being tracked in https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/package/mingw-biblesync.

See https://fedoraproject.org/wiki/Changes/CMake4.0 for more information on how to make the package compatible.

More specifically, depending on the state of the project:
- If it is actively maintained, please update the `cmake_minimum_required`, and instruct upstream to do so as well.
  To minimize future maintenance, please add a higher bound as well, preferrably with the highest CMake version being
  tested. You may use 4.0 as the higher bound as this is being tested in the tracked copr project.
- If the project is not maintained, you may add `CMAKE_POLICY_VERSION_MINIMUM=3.5` as a CMake variable or environment
  variable.

You can check the build locally following the instructions in the change proposal, or submit your build to the tracking
copr project.

Let me know if you encounter any issues, or need any other help.

Comment 1 greg.hellings 2025-07-16 15:36:08 UTC
This should be filed against CMake as a regression there. This code requires no changes to build with either CMake >= 4.0 or <= 4.0. Rejecting a correct minimum version of 2.8 simply because CMake maintainers no longer like the old version (or whatever other reason they've come up with) is a bug.

The minimum version of CMake required is 2.8. 4.0 still works.

CMake should be fixed to not force incorrect minimum version updates.

Comment 2 Cristian Le 2025-07-16 15:43:47 UTC
With all due respect, no, this is not a CMake issue, and CMake will remove policies every 3 years. The policies are by definition deprecated behavior and these have been deprecated for more than 10 years.

As indicated in the Change proposal document, if upstream is dead or do not want to adapt, than add `CMAKE_POLICY_VERSION_MINIMUM=3.5` in the spec file. But the preferred action is to contribute upstream with a high higher bound policy in order to minimize future maintenance.

Comment 3 greg.hellings 2025-07-16 16:22:21 UTC
Yes, this is a CMake issue. Literally not a single change to the CMake file is required except updating the minimum version? Why? It works just fine with CMake 2.8 with no changes. It works just fine with CMake 4 with no changes (except requiring the code to lie and say that it needs 3.5 or later).

That is a CMake problem. There is no reason that this library should drop support for older distributions simply because CMake wants the code to no longer be compatible with it, even when the code is perfectly compatible with it. Forcing a client application to declare itself incompatible with older versions of a tool when it is, in fact, not incompatible with that tool, is a bug in the tool making that demand.

Comment 4 Cristian Le 2025-07-16 16:40:44 UTC
CMake policies control behaviors that have/had backwards compatibility. When you populate `CMAKE_POLICY_VERSION_MINIMUM=3.5` you *are* making changes to how a project builds. It just so happens, that the CMake policies are often very neiche so many projects are not affected by it. You *do* need to rebuild with the appropriate policies bumped to make sure that the project does not actually use those. One example is that `test`, `check`, etc. target names are reserved and when the cmake policies are bumped, the build might fail if it did use those.

> There is no reason that this library should drop support for older distributions

Nobody is asking you to do so and *this is not what is being proposed here*

Ask upstream to change to
```
cmake_minimum_required(VERSION 2.8...4.0)
``` 
This *maintains* compatibility with lower cmake versions and adds forwards compatibility for all CMake versions up to 4.0 (and beyond using older policy behavior).

If you do not wish to interact with upstream use the following
```
%build
export CMAKE_POLICY_VERSION_MINIMUM=3.5
%mingw_cmake -DBIBLESYNC_SOVERSION=%{__soversion}
%mingw_make
```
(but in the spirit of upstream first, the former approach is preferred)

Comment 5 Fedora Update System 2025-07-19 16:26:32 UTC
FEDORA-2025-7e1da3d887 (mingw-biblesync-2.1.0-15.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e1da3d887

Comment 6 Fedora Update System 2025-07-19 16:28:29 UTC
FEDORA-2025-7e1da3d887 (mingw-biblesync-2.1.0-15.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 greg.hellings 2025-07-19 16:56:41 UTC
I presume that the Copr repo will pick up the rebuild automatically on a scheduled build?


Note You need to log in before you can comment on or make changes to this bug.