The binary packages for the beta and developer edition channels of Firefox aren’t getting updated in Nixpkgs at the same pace as the release channel—I recently submitted a PR that bumped both by two major versions. The update script for these packages works—I used it to create the PR—and I just discovered the existence of nixpkgs-update, which IIUC seems like it should be using that script to periodically submit bump PRs any time another Linux distribution offers a new version first.
I found the log for the most recent run of nixpkgs-update for firefox-devedition-bin-unwrapped here. It looks like it successfully created the diff that I’d expect, but there doesn’t seem to have ever been a PR for it in GitHub. Also, that run was from many days ago, and there have been beta releases of Firefox since then, but no runs.
What exactly is going wrong here, and how can I help out? Or am I wrong to expect these bumps to be handled automatically by the nixpkgs-update infrastructure?
Still interested in improving this. Here’s what I’ve figured out so far:
After nixpkgs-update runs the update script for the binary Firefox packages, it evaluates a set of ‘outpaths’ ultimately derived from pkgs/top-level/release.nix, and looks for any changes from before the update script was run. If there are no changes, the log will end with ‘Update edits cause no rebuilds.’
The binary Firefox packages aren’t included in this set of outpaths, so the changes induced by the update script aren’t detected.
The reason the binary Firefox packages aren’t included is because they have hydraPlatforms = []; in their meta attrsets. Based on code in pkgs/top-level/release-lib.nix, that attribute takes precedence over platforms when calculating the package set used by release.nix and thus by the outpaths-generating file used by nixpkgs-update. I have tested that removing hydraPlatforms = []; results in firefox-devedition-bin-unwrapped being correctly updated by nixpkgs-update update.
I’m still not sure what to do from here. It seems that the hydraPlatforms = []; was added intentionally, and it does make sense not to cache these packages in Hydra, as far as I understand. But of all the other moving parts involved here, I don’t know where the most appropriate place to suggest a change is. Should nixpkgs-update have an additional explicit list of packages to include above what is included in the release.nix package set? Should nixpkgs-update produce its list of outpaths from an altogether different source than release.nix? Or should the release-lib.nix machinery in Nixpkgs itself be modified to let the caller disable the hydraPlatforms override, so that nixpkgs-update can do just that when generating outpaths?
Anyone have tips for me? @ryantm, any chance you might be able to point me in the right direction?
Why does it make sense not to build them on Hydra?
I suspect the easiest change would be to make a list of packages that skip the outpath calculations. They’d need to say whether the PRs should target staging or master.
Building the packages in question basically entails downloading a binary from Mozilla and doing some lightweight transformations on top of that. So I can see an argument that, since these are not-trivially-small packages that are relatively fast to build and that update frequently, it isn’t worth taking up space in the Hydra cache with them. But I’m new to all of this; maybe we are used to thinking of Hydra space as virtually unlimited and we should cache these after all?
Thank you! I’ll take a shot at this and prepare a PR.