Home • Explore • Blog • Models • CI
☰



nixpkgs
18th chunk of `pkgs/README.md`
0c11ec650597a1f1990593c063aed6b8e4681fe56ae6a8480000000100000b53
- Ensure that the commit text [fits the guidelines](../CONTRIBUTING.md#commit-conventions).
- Ensure that the source is fetched from an official location, one of our [trusted mirrors](./build-support/fetchurl/mirrors.nix), or a mirror trusted by the authors.
- Ensure that the meta fields [fits the guidelines](#meta-attributes) and contain the correct information:
  - License must match the upstream license.
  - 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.
  - Uses the most appropriate functions (e.g. packages from GitHub should use `fetchFromGitHub`).
- Build the package locally.
- Run every binary.

Sample template for a new package review is provided below.

```markdown
##### Reviewed points

- [ ] package path fits guidelines
- [ ] package name fits guidelines
- [ ] package version fits guidelines
- [ ] package builds on ARCHITECTURE
- [ ] executables tested on ARCHITECTURE
- [ ] `meta.description` is set and fits guidelines
- [ ] `meta.license` fits upstream license
- [ ] `meta.platforms` is set
- [ ] `meta.maintainers` is set
- [ ] `meta.mainProgram` is set, if applicable.
- [ ] 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
- [ ] patches that are remotely available are fetched rather than vendored

##### Possible improvements

##### Comments
```

## Security

### Submitting security fixes

Security fixes are submitted in the same way as other changes and thus the same guidelines apply.

- If a new version fixing the vulnerability has been released, update the package;
- If the security fix comes in the form of a patch and a CVE is available, then add the patch to the Nixpkgs tree, and apply it to the package.
Title: Nixpkgs: New Package Review Checklist and Security Fix Submission Guidelines
Summary
This text details the concluding guidelines for reviewing new Nixpkgs packages, emphasizing adherence to commit conventions, fetching sources from official or trusted mirrors using appropriate functions, and accurate population of `meta` attributes (license, platforms, maintainers, `mainProgram`). It reiterates the necessity of documenting any special packaging choices, such as pinned versions, patches, or non-default build flags, and performing local builds and binary tests. A comprehensive markdown template for new package reviews is provided, covering checks from naming and versioning to `meta` fields, source fetching methods, and proper handling of build phases and patches. The chunk then introduces the process for submitting security fixes, stating they follow general submission guidelines and involve either updating to a new package version with the fix or applying a specific patch, especially when a CVE is available.