Best practices for updateScript for (e.g.) Wine

Development
1

I love updateScripts, and I love it when packages have updateScripts, because I love fresh packages and automated version bumps. I’d like to write an updateScript for the Wine package.

Wine has a complex structure in Nixpkgs. There are multiple top-level attributes corresponding both to different builds of the same Wine source code (wine, wine64) and different source trees (wine-staging, wine-wayland), and there are also package sets holding further variations, resulting in a few dozen distinct derivations. All of these derivations get their sources from a single sources.nix file (which also includes the source information for winetricks, for some reason, despite the main Wine packages not using winetricks directly). There are some interesting cross-dependencies inside sources.nix—for example, notice how unstable inherits gecko32 and gecko64 from stable but defines its own mono.

It’s nontrivial but ultimately not that hard to write a script that updates every version in sources.nix without changing any of the dependency structure, but to conform to the updateScript convention, is that the right thing to do? Which derivation should get that script as its passthru.updateScript—one, or all of them? Or should I instead try to write one script for stable, one for unstable, etc.—and if so, how should I handle the dependencies between the different sources? (And even then, since there are multiple derivations associated with each source, the same question as before: do they all get copies of the update script for a given source, or should only one of them?)

Is this ultimately a question for the Wine Nixpkgs maintainers or are there best practices for this sort of thing that I can reference as a starting point for a PR?

2

There is not really many conventions. Personally, I would look at how the software is updated. Hopefully, this was already reflected in how the manual updates were performed and so you could just try making the update script to emulate that.

GNOME, for example, consists of many interdependent projects that share a release schedule. But the coupling is loose enough to allow us updating each project separately. So each derivation has its own update script. (Ideally update.nix would update packages in topological order to make sure packages build at each update commit, in case a dependent raises a version bound but this is currently not supported.)

gmic, on the other hand, consists of several tightly coupled components, so we need to update them simultaneously.

Somewhere in the middle is, for example, Sublime Text, which has a stable and dev versions updated independently but each of the branches has a separate binary sources for multiple platforms. Or check blackfire for an even more complex example of the same – it has a separate PHP extension and agent program.

I tend to gravitate towards a single package/attribute per file, containing all the sources it needs. Then the package’s update script will update all the sources it uses. But in the end, it is up to the package’s maintainers.

There are not really many restrictions, apart from not having multiple update scripts update the same source, which could prevent from running them in parallel.