This comes up quite a lot in review, and we've just had a close call
with a known vulnerable library version almost being reintroduced
without appropriate knownVulnerabilities markings in an override in
the expression for a leaf package. Let's take the first step towards
preventing that sort of thing happening again.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Update scripts aren't always run in the development shell by default,
especially not in the regular automated updates.
The parent commit makes the update scripts depend on running in the
development shell, so let's make sure it's always done.
Motivation: Many package additions add unmaintained or otherwise problematic packages.
Many additions for browser forks, questionable encryption libraries or 10+ years unmaintained software exist.
These are frequently closed, but the expectations are not actually visibly documented.
Reword documentation to allow using `fetchpatch` for changes that are
not yet merged upstream. Additionally, put a greater emphasis on URL
stability.
fixes#400873
As of b01ca00aed (CODEOWNERS: Switch to alternate mechanism,
2024-10-10) and #336261, this repository doesn't use the GitHub
CODEOWNERS file, but instead has its own similar mechanism. Remove and
update references to the CODEOWNERS file in various documentation files.
Almost 1% of contributions in nixpkgs already use the unicode "→"
character instead of the two "->" ASCII characters to signal
a version upgrade. The guide only mentions "->", which sometimes
triggers discussions about the acceptable characters to use in
commit messages, with often a reference to the current README.md.
Some people prefer to use "→" because, depending on the font, it might
have a more appealing visual aspect than "->" and look better aligned.
Some others prefer to only write using the ASCII character set and will
use "->", but nowadays everyone can display common unicode characters
such as "→". Let us make everyone happy by indicating that both kind of
arrows are acceptable.
Found using https://github.com/serokell/xrefcheck, which unfortunately
can't trivially be enforced in CI because we also have the manual markdown
files that need post-processing to be valid
