The package set hasn't been working for a long time now, due to infinite
recursions, that nobody was going to fix.
The release is going to go EOL in 2023/06 and we don't want to ship it
in NixOS 23.05 anyway.
- This information is availabe from environment variables defined by
maintainers/scripts/update.nix
- Renamed the shell script to generic-update-script.sh
- Add a new optional argument (representing the package name) to the
shell script
- The version lister is called with a new optional
argument (representing the package attribute path)
When TOFU was unable to download the file, there would be no hash
in the fetch log, causing the grep to fail. Since the script
is set to errexit, it would terminate the processing without
any output. Let’s instead print the fetch log.
Some update scripts (e.g. sublime4) already use all-zeroes hashes
for resetting a version when updating multiple sources.
When `update-source-version "${attrPath}" 0 "${lib.fakeSha256}"`
was executed, u-s-v would not be able to detect that the hash
changed and would fail with the following message:
Failed to replace temporary source hash of '…' to the final source hash!
The update script worked when we tested it because change detection itself
was broken until recently: https://github.com/NixOS/nixpkgs/pull/190554
This would do a pointless slow `nix-instantiate` call for a feature
that is rarely used – initially, it was added for Firefox updates
186de9ca9e
but now not even that uses it.
Additionally, this would break stuff like `cargoDeps`,
which lack the url attributes.
Previously, we only made `sed` back up the version replacement.
This meant that `cmp` would already recognize the files
as changed before replacing hash and the other values,
and the error would not be printed.
Let’s always make the `sed` create a backup so that we can
detect success of each situation. This will no longer
allow us to revert to the original version on failure
but the updated file should be tracked in git anyway.
It used to use src.url, but when that was changed the comments weren't
updated.
Fixes: 7aae279ad9 ("unstableGitUpdater: fix updating fetchzip-based sources")
a67950f20b added `url` attribute
from `fetchurl` and therefore also from `fetchzip`.
We previously relied on `url` from fetchgit-based fetchers
to find the repo URL but now it will just return tarballs
in the case of `fetchFrom{GitHub,GitLab}`.
Let’s add an attribute to `fetch{git,FromGitHub,FromGitLab}`
to expose a repo URL consistently.
That way gitUpdater could be used to extract most recent published
releases for .nix files that don't use git directly to define builds.
An example is iproute2 package which does not have a single place
to lookup most recent release.
- Add the 'gitUpdater' helper function to update git based packages, using the
'genericUpdater' function.
- Rework argument passing to the `list-git-tags' and 'list-archive-two-level-versions' scripts.
- Replace 'genericUpdater' plus 'list-git-tags' by 'gitUpdater'
It is important to keep the version as parsed by `builtins.parseDrvName`
monotonic for packages that often switch between stable and unstable versions,
for nix-env to be able to update them reliably.
Let’s optionally use the version format described by RFC 107:
https://github.com/NixOS/rfcs/pull/107
The downside is that it requires fetching
more commits to be able to determine the latest tag.
When `fetchFromGitHub` uses `fetchzip` instead of `fetchgit` internally,
which is the most common use case, there is no `src.url` attribute
so the update will fail.
Let’s fix that by falling back to `src.meta.homepage`,
which these fetchers set to the repository URL.
In flakes, packages are not exposed directly but instead they are declared
inside “packages” or “legacyPackages” output under their host platform.
flake-compat reflects this.
Let’s look for an attribute also in these outputs if the direct lookup fails.
When update-source-version is run in a repo with flake-compat,
it would find the files in Nix store.
Let’s replace them with the local path of the repository.
John Titor