I’m trying to figure out the role of passtrhu.updateScript for maintainers.
The following questions come to mind:
-
if a package has such attribute, would there be no need of manual intervention in cases which the update only needs a new version and hash attributes or others like the ones supported by GitHub - Mic92/nix-update: Swiss-knife for updating nix packages.?
-
Would the role of the maintainer be relegated to deal with breaking changes related to the package? For example, the package changed its build framework from foo to bar, causing a simple update of version and hash not capable of updating it, since it would be missing a build dependency — foo would be in nativeBuildInputs while bar would not.
-
Would there be any downsides of using such attribute?
Welcome!
Having an update script doesn’t currently change the fundamental flow of Nixpkgs maintenance:
- Someone updates the package locally and submits a PR
- Someone reviews and tests the PR
- The submitter fixes any problems that arise in manual or automated testing
- Someone merges the PR
Having an update script only means that a first draft of step 1 can be done automatically (and if a human doesn’t do it, the r-ryantm bot can eventually get to it, in theory—in practice, there is a list of packages nixpkgs-update is programmed to ignore, and also some amount of spooky jank in the infrastructure that I’m currently working on reducing). Even if one draft is all that’s needed, steps 2 through 4 are still necessary.
You’re right that some updates require more manual intervention than others. It’s also the case that an update script, like any bit of automation, is only as good as its inputs. If the upstream repository mis-tags a version, or changes their versioning policy, or if the update script wasn’t written (or invoked, since the majority of update scripts are references to one of the default scripts) with enough care, then r-ryantm might submit a PR with a version that isn’t an update you want.
1 Like
Thanks for the clarification!, @rhendric.