gador/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

CONTRIBUTING: Add guideline to document motivation for special packaging choices (#416728)

Browse Source
This commit is contained in:
Wolfgang Walther
2025-06-27 18:49:30 +00:00
committed by GitHub
parent 88411ff8c6 0930b566b8
commit 784eeb79fd
1 changed files with 12 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pkgs/README.md
+12
View File
@@ -953,6 +953,11 @@ Reviewing process:
- Verify any change of upstream.
- If switching from e.g. PyPi to GitHub, verify that the repo is the official one.
- If switching to a fork, check with external sources like other package repositories for community consensus.
- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment.
- If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
- If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
- If any non-default build flags are set, document why.
- If checks are partially or fully disabled, document why.
- Ensure that the code contains no typos.
- Build the package locally.
- Pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds.
@@ -984,6 +989,7 @@ Sample template for a package update review is provided below.
- [ ] package builds on ARCHITECTURE
- [ ] executables tested on ARCHITECTURE
- [ ] any change of upstream are verified
- [ ] the motives for any special packaging choices are documented
- [ ] all depending packages build
- [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed
- [ ] patches that are remotely available are fetched rather than vendored
@@ -1009,6 +1015,11 @@ Review process:
- Platforms should be set (or the package will not get binary substitutes).
- Maintainers must be set. This can be the package submitter or a community member that accepts taking up maintainership of the package.
- The `meta.mainProgram` must be set if a main executable exists.
- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment.
- If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
- If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
- If any non-default build flags are set, document why.
- If checks are partially or fully disabled, document why.
- Report detected typos.
- Ensure the package source:
- Uses `mirror://` URLs when available.
@@ -1034,6 +1045,7 @@ Sample template for a new package review is provided below.
- [ ] build time only dependencies are declared in `nativeBuildInputs`
- [ ] source is fetched from an official or trusted location
- [ ] source is fetched using the appropriate function
- [ ] the motives for any special packaging choices are documented
- [ ] the list of `phases` is not overridden
- [ ] when a phase (like `installPhase`) is overridden it starts with `runHook preInstall` and ends with `runHook postInstall`.
- [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed