​​nixpkgs Merge Queue - Easy Mark Broken v0
​​​+nixpkgs Merge Queue - Overview​
​​
​​feature
​​start-date
​​author
​​co-authors
​​
​​shepherd-team
​​shepherd-leader
​​related-issues
​​(fill me in with a unique ident, my_awesome_feature)
​​(fill me in with today's date, YYYY-MM-DD)
​​(name of the main author)
​​(find a buddy later to help out with the RFC)
​​
​​(names, to be nominated and accepted by RFC steering committee)
​​(name to be appointed by RFC steering committee)
​​(will contain links to implementation PRs)

​​Summary

​​This provides an easy way to mark packages as broken. Currently it is very toilsome to mark a large number of packages broken. This is a significant burden on maintainers of highly depended-on packages such as common libraries and build tools.

​​Motivation

​​In the ​+nixpkgs Merge Queue - Breaking Change Policy​ it is expected that package owners will mark broken dependents as broken. Currently this is quite toilsome as it requires going from derivation path to the source file that declared it and updating the source.

​​Detailed design

​​In order to make automation simple broken packages will be broken out into a separate file called broken-packages.json​. This file will simply contain a mapping of values from package name to the value true​.
​​
​​{
​​  "abacus-10.2": true,
​​  "calcualtor-1.5": true,
​​  ...
​​}
​​
​​stdenv.mkDerivation​ will then be updated to check this file when considering brokenness in addition to the broken​ attribute.
​​
​​The tool will analyze build logs from a tool such as ofborg​, hydra​ or nixpkgs-review​ and then add the failing derivations to this file.

​​Examples and Interactions

​​This section illustrates the detailed design. This section should clarify all confusion the reader has from the previous sections. It is especially important to counterbalance the desired terseness of the detailed design; if you feel your detailed design is rudely short, consider making this section longer instead.

​​Drawbacks

  • ​​This makes all derivations depend on a single, frequently changing file. This may make this solution unsuitable if smarter incremental evaluation support is added to nixpkgs CI.
  • ​​This creates a second place where derivations can be marked as broken which may be confusing to readers.

​​Alternatives

​​Make a tool that marks packages as broken in their source definition

​​This tool is theoretically possible but depends on a number of features that are not yet available in the Nix ecosystem.
​​
  • ​​Mapping from derivation to source location.
  • ​​Editing source files with little to no disruption of formatting.
​​
​​Furthermore often different versions of a derivation are declared in the same file. In order to support this the tool would have to either ignore this, and mark them all as broken without human intervention or learn to generate possibly complex conditionals to select only the correct derivations.

​​Add annotations to packages instead of using an external JSON file

​​stdenv.mkDerivation {
​​  name = "foobar"
​​
​​  meta = {
​​    broken = false; 

​​Unresolved questions

  • ​​How much of a problem will derivations that share the same name/version be. (Example git​ and gitFull​).

​​Future work

​​