No, we're not doing this. Please fix the software that's affected - the fixes are in most cases trivial.

Closing, as this is not going to happen.

No, we're not doing this. Please fix the software that's affected - the fixes are in most cases trivial.

I guess the main use-case for this would've been older nix-shells, not packages in nixpkgs.

I agree that whenever possible we should update/patch packages to use CMake 4.x
but CMake 3.x is not EOL and still receiving updates from CMake (e.g. recently-released 3.31.9)

I agree that whenever possible we should update/patch packages to use CMake 4.x
but CMake 3.x is not EOL and still receiving updates from CMake (e.g. recently-released 3.31.9)

I think the argument for removal was that it will be EOL during the lifetime of 25.11 and we can't make such a change on the stable branch then. At least that's what I understood.

To be clear: The update to CMake 4 is not actually breaking. It's just that a lot of CMake files just pin too old CMake versions. So the vast majority of projects just does not need CMake 3. It's just a tiny change to change their compatibility policies correctly. This is not materially different from pinning packages to use older CMake versions - with one big difference:

Reintroducing CMake 3 and pinning it for packages will push the whole additional work of getting rid of it to a single person: The one person who is going to try to remove old, outdated CMake, when it is time. This person is highly likely one of these persons, who is working on staging stuff anyway, so it will just put even more work on these people.

Fix packages 1-by-1, once the package updates upstream, the replace/patch or whatever fails - the work is distributed among all maintainers.

I still cant find a reference to cmake 3 being EOL. It'd be great to link to their announcement of it.

Having a separate cmake3 package wont change anything in nixpkgs wrt build failures or current work, they all point to cmake. No one is arguing that nixpkgs itself shouldn't choose and put it's effort to cmake 4 now if they like - but it's leaving a lot of users who use nix-shell/env/etc in the lurch and adding 40 lines of an overlay is not a trivial thing to do for everyone (me). As well as 3rd party apps and libraries I'm using.

Having more work arounds for end users just makes it harder for people who want to use nixpkgs to get work done.

but it's leaving a lot of users who use nix-shell/env/etc in the lurch

What stops you from adding the same compatibility policy to your projects instead? These are really simple changes.

@K900 @wolfgangwalther what are we doing here?

It seems to me you're trying to unilaterally force a change in package maintenance culture, without understanding everything that has been and is going on. Please take a step back from the keyboard and let the community fix the breakage you've forced down everyone's throat.

What stops you from adding the same compatibility policy to your projects instead? These are really simple changes.

Sure, they might be, but I already have many "simple" work arounds in my nix-shells that add up. I also don't control all 3rd party builds I use. I can work around this. But, again, since cmake3 seems to be an active, maintained version, I don't understand why.

Imperfect counter example: nixpkgs has jdk8-jdk24 - It's "simple" to update to jdk24 - jdk24 will run jdk8 bytecode and compile it, etc, etc. but jdk8 is maintained (probably forever :D).

You can make your consumers work around any issue, but in this instance I'm just not seeing why.

There were no specific reasons given to make this change.

From the PR summary:

CMake 3 is still useful for a lot of software.

This is a reason. It should be enough. It is enough for PLENTY of software that has been and will be going into nixpkgs. Are we playing favorites here?

Reintroducing CMake 3 and pinning it for packages will push the whole additional work of getting rid of it to a single person: The one person who is going to try to remove old, outdated CMake, when it is time. This person is highly likely one of these persons, who is working on staging stuff anyway, so it will just put even more work on these people.

I sympathize with this sentiment, but expunging a package that's useful to many people is the wrong way to go about this. And blocking this PR is a complete non-sequitur.

This PR is also not the place to discuss how to lighten the staging team's load or who should be responsible for removing old packages. So I won't.

I think the argument for removal was that it will be EOL during the lifetime of 25.11 and we can't make such a change on the stable branch then. At least that's what I understood.

This is not a good reason to throw out a build system that's in use. I don't think we have LTS releases, so how long do you estimate is the lifetime of a release? IOW if we err on the side of caution here, how long do you think we'd be plagued by cmake 3 in a stable release? And what do you think is the worst case outcome?

Would you agree that the advantage of EOL software is that it doesn't change anymore and thus won't need to be updated any more, thus making the support load non-existent?

@wolfgangwalther

There were specific reasons given not to make this change.

Did I answer all your specific reasons in this comment?

There were no specific reasons given to make this change.

As per my previous comment, there was a specific reason already in the initial PR summary. Do you disagree?

As per my previous comment, there was a specific reason already in the initial PR summary. Do you disagree?

Yes, I disagree. "CMake 3 is still useful for a lot of software." is not a specific reason. On the contrary it is about as unspecific as one could think. Once you hit a package that can't be made to work with CMake 4, because it actually relies on older features - then there is a specific reason.

The proposed fix - reaching into source packages to patch cmake files - is not reasonable to expect from maintainers.

Yes, it is.

The proposed fix - reaching into source packages to patch cmake files - is not reasonable to expect from maintainers.

Yes, it is.

You forgot about a crucial part, when quoting me:

Especially on such a large scale, on such a short - forced - time frame.

The proposed fix - reaching into source packages to patch cmake files - is not reasonable to expect from maintainers. Especially on such a large scale, on such a short - forced - time frame.

Yes, it is.

(OK, sorry but that was an invitation :D)

On a more serious note: Yes, it is reasonable, even on this time frame, because ZHF is coming up, which will be perfect for this.

The proposed fix - reaching into source packages to patch cmake files - is not reasonable to expect from maintainers. Especially on such a large scale, on such a short - forced - time frame.

Yes, it is.

(OK, sorry but that was an invitation :D)

I appreciate that you can make light of the situation, but I'm not in the mood for your jokes, right now.

On a more serious note: Yes, it is reasonable, even on this time frame, because ZHF is coming up, which will be perfect for this.

I don't know what a ZHF is and I don't know why my updates should be blocked for it. All you're doing here is making me feel like an outsider with no place in the community. I don't assume that's what you're trying to do, but your nonchalance about abusing version updates to force everybody to do work is deeply worrying to me.

I don't know what a ZHF

ZHF is the zero hydra failures campaign that is part of every release. See #443568.

All you're doing here is making me feel like an outsider with no place in the community. I don't assume that's what you're trying to do

Certainly not, no!

but your nonchalance about abusing version updates to force everybody to do work is deeply worrying to me.

The alternative is - no update. That's not what unstable is about. If you don't care about the latest stuff - you'll need to use the stable release branches. Also see #445447 (comment).

The alternative is - no update.

That's just plain false. This kind of rhetoric - excluding the middle - is exactly what's wrong about the whole approach of "break it and they will come (fix it)".

That's not what unstable is about.

Unstable is many things to many people. Why should I care about what you're getting out of it, if you don't care about what I'm getting out of it?

If you don't care about the latest stuff - you'll need to use the stable release branches. Also see #445447 (comment).

Oh, I care. I just don't listen to the war drums and I - like many people - found my home in nixos because it allowed me to get away from the endless toil and breakage, prevalent in other distributions.

Your implication - that using stable branches will shield me from breakage - is laughable, when nobody who cares about compatibility is watching unstable and if support for stable releases is hard cut after 6 months.

Also, if you don't want to make me feel like an outsider with no place here, why are you using exclusionary language again? Has this kind of argument really grown that popular in nixpkgs?

Per #445447 (comment), we do already effectively package CMake 3 – some 27 minor versions of it, in fact, starting at 3.5, because CMake has native backwards‐compatibility functionality to emulate old versions. We can “pin” a version like CMake 3.10 for packages that haven’t updated upstream by setting the policy version – this is just a matter of adding cmakeFlags = [ (lib.cmakeFeature "CMAKE_POLICY_VERSION_MINIMUM" "3.10") ];, rather than changing cmake to cmake_3_10. So reintroducing cmake3 won’t make handling the fallout meaningfully easier, as it’s just swapping one method of pinning for another, and old versions introduce their own maintenance burden – as I explained in my other comment, what we’re seeing here is a consequence of many upstreams pinning an old version for compatibility, even after it started to come with warnings about its upcoming removal.

It’s true that we prefer upstreamable solutions, and to not to add flags that will become obsolete, where we can avoid it – but a substituteInPlace to patch the policy version is only a few additional lines, and the flag is perfectly acceptable if there are a bunch of nested CMake files that would need elaborate patching. Thankfully, as we are already behind other distributions on the upgrade to CMake 4, most active upstreams already have fixes available – whether in new released versions we can bump to, merged commits we can fetch, or patches in upstream PRs or from other distributions that we can pick.

Our written guidelines specifically advise against packaging multiple versions unless necessary:

Because every version of a package in Nixpkgs creates a potential maintenance burden, old versions of a package should not be kept unless there is a good reason to do so. For instance, Nixpkgs contains several versions of GCC because other packages don’t build with the latest version of GCC. Other examples are having both the latest stable and latest pre-release version of a package, or to keep several major releases of an application that differ significantly in functionality.

How many packages need to regress to justify packaging multiple versions is of course a judgement call. The versions for which CMake 4 has removed emulation support are all a decade or more old; we have removed LLVM and GCC versions that are much younger than that. In this case, the initial batch of fixes only uncovered one or two packages that needed any changes beyond the equivalent of a version pin, and although I haven’t reviewed all of the many subsequent fix PRs, I would expect that very few of those packages require anything more than that. Since we can still pin the behaviour of CMake 3.5 from 2016, as far as I’m aware, there have been less than a handful of true regressions here – regressions that cannot be fixed simply by opting in to a newer compatibility version with the same work as a version pin, instead requiring actual patches of the CMake files to not rely on behaviour that was deprecated and changed a decade ago. That’s well below the bar we package multiple versions for, so I don’t think it makes sense to go against standard practice to do so here.

(I recognize that there have been many regressions from packages requesting compatibility with ancient CMake versions even though they don’t need it – but those wouldn’t be fixed by merging this PR. There would still need to be changes to those packages relating to the CMake version. I’m just saying that since our CMake 4 already supports all the way down to CMake 3.5 and very little seems to actually require behaviour older than that, this PR does not make almost any of those changes easier, in comparison to the costs.)

As I said, I don't want to participate in the edit war on github. I will say that this authoritative behavior of just re-closing worries me deeply, but other than the original participants, I have faith in the rest of the community to draw the right conclusions, so I'll lay off of this.

In the meantime, I'll use this comment to collect actually constructive feedback and suggestions:

• Arian on Matrix suggested: "Can't we make cmake3 an alias of cmake4 that injects the CMAKE_MINIMUM_REQUIRED_VERSION env var in a setup hook?"

@bjornfor I think you did say that you needed cmake 3 for your own work do you?

I don't personally need it for any packages I maintain, nor for anything out-of-tree, but if you need it, I'm willing to step up as a co-maintainer.

@bjornfor I think you did say that you needed cmake 3 for your own work do you?

No, I don't think so.

I made this PR because of the fall-out / seeing that a lot of software isn't directly compatible with CMake 4, and that some people asked for it (in the referenced issue/PR).

As I said, I don't want to participate in the edit war on github. I will say that this authoritative behavior of just re-closing worries me deeply, [...]

Same.

I am sorry if it came across as authoritative, @bjornfor. I think it is generally better for PRs to have a clear yes‐or‐no outcome rather than stalling out indefinitely, but I also recognize that we currently do not have clear criteria for when those judgement calls can be made, and I also wouldn’t want to override community consensus.

In this case, my core argument is: CMake’s version compatibility mechanism already offers us the ability to pin the behaviour of old versions down to 3.5. It requires a single flag to do so, which is no more complicated than switching the cmake dependency to a versioned pin would be. Therefore, this PR would not eliminate the need to do these version‐pinning fixes – the fallout consists almost entirely of needing to pin a version, which would still be required after this PR – and would not make the fixes being done any simpler, and so there is no reason to go against the written guideline against packaging multiple versions. It did not seem like this was taken into full consideration in the discussion, so I hoped that explaining CMake 4’s native compatibility mechanism with CMake 3 versions back to 2016 would clarify why this copied package does not seem necessary and would not mitigate the fallout more than our existing options.

If you feel that CMake’s built‐in version compatibility is inadequate to meet the need then that would be a counterargument here. For instance, if there were a meaningful number of packages that depended on the actual behaviour of CMake versions older than 3.5 from a decade ago, rather than simply having an outdated pin, then the old version would add value that cannot be achieved with the compatibility flag. My experience from having put weeks of work into the CMake 4 migration with a few other contributors was that we only ran into one or two packages like this, and the fixes to the CMake files were trivial in those cases and already sent upstream by others, so the “effective fallout” was very limited and wouldn’t meet our usual bar – the packages we ran into only required “pinning” down to CMake 3.5 or 3.10, with very few exceptions.

If more people run into cases like these, though, then there would be an argument to assess the trade‐off of the burden of patching them vs. the maintenance of two CMake packages and the likely addition of unnecessary pins to it across the tree that would complicate future clean‐up. Again, though, my judgement here was based on my perception that, in the cases I have seen, we can already pin CMake 3 behaviour without any additional package and as simply as pinning a dependency would be, and so the practical need this package would add is already being met.

@emilazy: Thank you for the response. I understand you put effort into this; both the cmake change itself, and the follow up discussions. I appreciate that.

I don't want to drag this out much further, but even after all that's been said, there's one thing I don't understand. I don't need this answered, I just want to say out loud what I'm thinking.

It's been argued that we need to pin old cmake behaviour either way, with cmake3 or with cmake4 + flag. If that are the only options, I guess cmake4 + flag is OK. But isn't there a third option, to introduce cmake4 and leave cmake be version 3 for a while longer? How much software is going to require cmake4 features in the next 6 months? Is pinning cmake4 for those packages going to be more work than pinning existing software to cmake3? Some people say cmake3 is EOL. I haven't seen any evidence of that, but even if it is, it's still the same software that has been working fine until now. What are we afraid of? That it doesn't get a patch update in the next 6 months (during a NixOS stable support period)? That some cmake dependency gets updated and it breaks cmake? That there'd be CVEs? Are we trying to protect users somehow? I don't want nixpkgs to so eager to "protect" me like that. The latest Ubuntu LTS (version 24.04) has cmake 3.28, and that's supported for years to come. If I were to decide, I'd keep cmake 3.x around as the default cmake until it causes a (real) problem -- I wouldn't want to do preemptive removal, because I don't see who benefits from that. I know cmake 3 must be removed from nixpkgs at some point, but why do we have to be so eager to do it? The eager removal does seem to come at a cost to me. But it seems proponents of cmake3 removal see it the other way.

(This became 10x what I planned to write. Sorry 😄)

Hope you don’t mind me answering anyway :)

The cost of any given old package is not high by itself, in the absence of security issues. However, habitually keeping old versions of software around has a high maintenance cost: old software will often break when used with new compilers and libraries, which necessitates either manual backporting work or keeping around old versions of those dependencies – which then repeats in turn, until there is an entire load‐bearing shadow dependency tree of old versions. And then one of those old versions doesn’t work with a new Linux kernel version, macOS release, or CPU architecture… or has a serious security vulnerability… and the real pain begins.

On top of that, any other necessary fixes or behavioural changes will often have to be repeated across multiple versions, if they are widely used. It’s also very common for unnecessary pins of old versions to be introduced and then not resolved even after upstream fixes (automated ratchet checks would help here, but I’ve found it’s essentially impossible to prevent with manual review). That means that packaging multiple versions by default would cause exponential maintenance burden; indeed, whenever some staging work causes a regression in old versions of a multi‐version package, I do my best to try and eliminate it by bumping old users rather than patching around it, because I know it’s only a matter of time until the next problem. (Recent examples from the CMake 4 and LLVM 21 bumps: #441569, #443319, #443325, #442554, #442977.)

Using packages from an old Nixpkgs release is a much more reliable way to get working versions of old software without exploding the complexity of Nixpkgs maintenance. But of course we don’t have a hard rule against packaging multiple versions, only a guideline recommending against it where avoidable. In the case of significant fallout, especially with packages that make habitual breaking changes, multiple versions can be justifiable.

For things like compilers or widely‐used build systems, projects do want to use new features once they’ve hit major distributions (a bit of a catch‐22! – but we certainly experience pain quickly when we fall behind on e.g. Rust versions), and the reverse dependency closure is so large that single‐handedly dealing with – or even just assessing – each regression is not feasible. The ideal case would be to have run a full jobset build with nothing else in it and then automatically triage the fallout to package maintainers before merge. That requires Hydra resources, time, and tooling we don’t really have, though – and Haskell maintainers have found that even with tooling like that they end up triaging and fixing more regressions than a small team can really sustainably manage. As I said in my other comment, it’s a shared desire of the Nixpkgs core team to improve the situation here, but we’re not there yet, and can’t really stop updating everything until we get there.

The EOL concern is not a major factor for CMake specifically in my view; CMake is not completely security‐irrelevant (it is a networked interpreter that runs with high privileges on developer machines!), but not the central case of a package where we really want to drop a version as soon as it goes EOL. It is more salient for other packages, although on long enough timescales I would expect to see issues like “the old version of CMake requires insecure versions of OpenSSL and Expat”. (Whether CMake 3 is actually EOL or not, I am not sure. They have a formal support schedule for policy versions, but seemingly not for the actual codebase that I could find. There seem to have been recent bug fix releases, so I’d err on the side of assuming that CMake 3 will be maintained on a best‐effort bug fix basis for a little while longer.)

CMake is a weird case: they are so dedicated to backwards compatibility that even though the current release supports emulating versions up to a decade old, it was so easy to pin a request for strict compatibility with an old version and forget about it that just those unnecessary pins themselves are causing issues. We are now experiencing precisely the pain we’d have if we packaged separate versions of CMake for an entire decade and then had to drop the oldest ones.

Since CMake 4 provides practical backwards compatibility for old versions, I think the intermediate state would have been not to introduce two separate packages, but to make our CMake hook automatically bump the minimum policy version to 3.5. This would have broken only the very small number of packages that truly require policy versions older than that, without incurring the full costs of a complete up‐front migration. However, it’s a divergence from upstream behaviour that would hide potential issues – and at some point they will phase out earlier policy versions again. So that is not a stable long‐term state.

You’re right that the major decision we could make is when to flip the default and cause these issues that were previously warnings in CMake 3 to become the hard errors – at some point we have to do it, and some fallout is inevitable. The big question is whether we would see significantly less fallout if we waited. CMake 4.0.0 was released in March, before the 25.05 freeze, so we already skipped an entire release cycle and a half.

Would delaying CMake 4 by default to 26.05, over a year after it was released, have caused significantly fewer regressions? I am not sure. Arch and Alpine already offer CMake 4 exclusively and Gentoo also did an update quite early. I understand that most Windows users seem to be getting CMake 4 exclusively too, from seeing PRs and issues around the place while working on the transition. Many of the regressions I saw already had merged upstream commits that had not yet reached a stable release. On the other hand, some of those projects hadn’t cut a stable release in years, so waiting for an update rather than patching would not have been feasible.

In other cases, there was already an upstream release with a fix – but we hadn’t updated to it in Nixpkgs. Sadly, a lot of packages just don’t get updates and other maintenance from their listed maintainers in a timely manner, and it falls on people doing wide‐scale changes to handle them. Those would have regressed no matter what.

Finally, there were a lot of projects that had open upstream fix PRs that weren’t getting reviewed in a timely manner, or whose development was moribund in general. Waiting would be unlikely do much good for those, and it was a substantial number of the regressions I saw.

In general, I would say that the ecosystem has not yet reached steady‐state in terms of upstream fixes, but that it’s much more ready now than when CMake 4.0.0 was released. As we are one of the largest software collections, even if we switch after other major distros, it’s inevitable that there’d be regressions – much of the work to fix software upstream for new versions of dependencies is driven by distribution maintainers, and a downside of packaging so much stuff is that we can’t always piggy‐back on the work of other distributions even when the packages have active upstreams.

I think waiting half a year got us the majority of the total benefit we’d get from other distributions. Since CMake had already been warning that support for these old policy versions had been removed for a while, and since you had to pin a compatibility version that is a decade or more old to run into issues here, I would guess that most of what remains would not move in a timely manner by itself. Thankfully, each individual case is very easy to fix in Nixpkgs – and I believe that we have already had the version bumps accepted upstream in some cases, which at least helps move the whole ecosystem forward and pays off some of the freeloading we’ve done on other distributions’ work :)

As I said in my comment on the tracking issue, I unfortunately missed the staging-next rebuild cycle where CMake 4 became the default – otherwise I would have done my best to fix failures that pop up during that that weren’t found by the existing testing, especially in non‐leaf packages that have substantial dependencies. That probably exacerbated the fallout people are seeing, sadly.

Whether it would have been best to delay to 26.05 and possibly deal with the costs of having to package CMake 4 separately for that period, I am not sure; my feeling is that it would not have changed the pain significantly and so it’s best to do it now, but there’s a large element of gut feeling in these judgement calls. I do think that now we’re here, reintroducing CMake 3 wouldn’t ease migration of almost any regression compared to the flag.

From my POV, we’ve already experienced a majority of the resulting pain and delaying what remains further probably isn’t a great trade‐off, especially with Zero Hydra Failures coming up, and since even an immediate change to the default CMake version or the hook would take about month to reach master from staging at this point – there’s no quick fix at this point. But of course I sympathize with people frustrated that their system update is blocked on a regression, and hope we can achieving the tooling improvements that would make this sort of thing less of a bumpy ride on the unstable channel.

(This became 10x what I planned to write. Sorry 😄)

(Yeah, me too…)