Packaging upstream when there's already a fork using the upstream name

I wanted to add openzwave support to domoticz. It was pretty straightforward to do (See my branch with the necessary changes), and I have been using it for a few months now. However, there is an issue which prevents me contributing the change to nixpkgs in its current state: There is already a package called “openzwave” in nixpkgs, but it’s built from a fork, home-assistant/open-zwave rather than the upstream OpenZWave/open-zwave. The two branches have significant differences, and the home-assistant one is not compatible with domoticz.

Simply changing it to build from the upstream sources (as I have done in my branch) almost certainly breaks home-assistant, which was previously the only package that depended on openzwave.

If we were starting from scratch, without any openzwave package I assume the logical thing to do would be to have two packages, one called openzwave, built from the upstream sources, and one called something like home-assistant-openzwave, built from the fork and with that fact clearly stated in meta.description.

Given that we already have the home-assistant version using the openzwave name, should we:

  1. Make openzwave the upstream version, and create a new package for the home-assistant version. We can avoid breaking home-assistant by changing it to depend on the new package. The only problem would be if a user has their own default.nix, shell.nix or configuration.nix which depends on pkgs.openzwave and expects the home-assistant version (Though presumably a simple version update could break their system just as badly).
  2. Assume that package names are allocated on a first-come-first-served basis and shouldn’t change meaning. Leave the existing openzwave package alone and package the upstream version as something else, e.g. openzwave-openzwave or the-real-openzwave.

One argument in favour of changing openzwave to be the upstream package is that people searching for an openzwave package in nixpkgs will probably expect the upstream one unless it is clearly labelled. This tripped me up at first when I tried to write a little C++ zwave application. I assumed that entering a nix-shell with openzwave would work, and it took me a while to work out why the API didn’t seem to match the docs I was reading.

It does look like the home-assistant fork may have been abandoned (the github repo is archived), so maybe home-assistant is supposed to work with the upstream openzwave now, or has dropped openzwave support?

I did have one other issue, although I’m not sure if it would be better to create a separate thread for that. Making domoticz work with openzwave also requires the domoticz systemd service’s user to be in the dialout group. At least it does on my system where the ZWave controller is a serial device. I just added SupplementaryGroups = [ "dialout" ]; to nixos/modules/services/misc/domoticz.nix, which works fine for me, but I’m not sure that’s the “right” way to do it.

1 Like