Skip to content

config: make allowBroken actully allow everything marked as broken#534854

Open
jopejoe1 wants to merge 1 commit into
NixOS:masterfrom
jopejoe1:config-broken
Open

config: make allowBroken actully allow everything marked as broken#534854
jopejoe1 wants to merge 1 commit into
NixOS:masterfrom
jopejoe1:config-broken

Conversation

@jopejoe1

Copy link
Copy Markdown
Member

Noticed this while working on #533355

Things done

@jopejoe1 jopejoe1 requested a review from infinisil June 24, 2026 08:35
@nixpkgs-ci nixpkgs-ci Bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Jun 24, 2026

@infinisil infinisil left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be great to add more context to this, but I was able to figure it out:

Currently broken = true only causes problems.broken to be generated when allowBroken = false. So if allowBroken = true, no problems.broken exists, and so no error is thrown. But if somebody sets problems.broken directly, there's nothing that prevents it from throwing an error with allowBroken = true.

While this fixes the immediate problem, it's not entirely right, because there's also NIXPKGS_ALLOW_BROKEN and allowBrokenPredicate. Instead the right fix I believe is to move the entire allowBroken logic from the automated problems.broken to the mkIf conditional.

Comment thread pkgs/top-level/config.nix Outdated
@@ -512,10 +512,10 @@ in
# Put the default value for matchers in here (as in, not as an *actual* mkDefault default value),
# to force it being merged with any custom values instead of being overridden.
problems.matchers = [
{
(lib.mkIf (!config.allowBroken) {
kind = "broken";
handler = "error";

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also a question whether we should do

Suggested change
handler = "error";
handler = if (config.allowBroken ...) then "warn" else "error";

or

Suggested change
handler = "error";
handler = if (config.allowBroken ...) then "ignore" else "error";

Traditionally at least it was ignore, but I'd argue we should make it a warn, because allowBroken is such a heavy-handed toggle, while users now also have the option to individually set problems.handlers.<somePackage>.broken = "ignore".

@Sigmanificient Sigmanificient changed the title config: make allowBroken actully allow evrything marked as broken config: make allowBroken actully allow everything marked as broken Jun 24, 2026
@jopejoe1

Copy link
Copy Markdown
Member Author

Im currently not seeing how it would be possible to migrate allowBrokenPredicate to the current problems options with out rewriting it a bit to make it possible to handle predicates as matchers.

@nixpkgs-ci nixpkgs-ci Bot added the 6.topic: stdenv Standard environment label Jun 24, 2026
@github-project-automation github-project-automation Bot moved this to In Progress in Stdenv Jun 24, 2026
allowBrokenPredicate =
lib.warnIf (lib.oldestSupportedReleaseIsAtLeast 2605)
"config.allowBrokenPredicate is deprecated, use config.problems.handlers.myPackage.broken = \"warn\" for individual packages instead."
config.allowBrokenPredicate;
in
if allowBroken then

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was on purpose to allow not checking for brokenness when allowBroken is true. Is there a way to get this back?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should that not already be the case when the handler is set to ignore? If not i would be very concerned about adding any new automaticProblems to the list.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It used to not do that until I fixed it in #519600 - but yes, you're right. Just confirmed myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: stdenv Standard environment 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux.

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

3 participants