CONTRIBUTING: Add guideline to document motivation for special packaging choices (#416728) (784eeb79) · Commits · nix / nixpkgs

pkgs/README.md

+12 −0

Original line number	Diff line number	Diff line
		@@ -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

Admin message