Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
wolfgangwalther merged 1 commit into from
Jun 27, 2025
Merged

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions pkgs/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -946,6 +946,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.
Expand Down Expand Up @@ -977,6 +982,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
Expand All @@ -1002,6 +1008,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.
Expand All @@ -1027,6 +1038,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
Expand Down
Loading