I have a project where I wanted to configure a laptop with various conference platforms and I thought it would be a nice way to learn more about NixOS, so I started to dive in. One of the conference platforms that I wanted to install, Webex, only offers an RPM or DEB. However, after a lot of reading, along with an equal amount of trial and error, I actually have it working on a NixOS laptop.
For now, I’m just downloading the current release and then pointing the overlay (if that’s the right term) to the local .deb file for building directly from that. I think I’d prefer to point it to the actual download location that webex offers, but they don’t seem to have a “versioned” download, they just offer the current release as far as I can tell. I can probably just download and host a versioned webex_version.deb for my own project needs on a webserver, but what would I do about this issue if wanted to somehow share my webex.nix upstream with the community? I guess not including a checksum for the download would get around this issue, but perhaps isn’t best practice; does that even work?
That won’t work, since nix will refuse to download anything without a checksum, and upstream won’t allow you to merge a package that outright doesn’t build. Even if this was possible, it’d be far too much effort for anyone to install the package, since they’d have to go override the checksum.
I’d also call that somewhat ethically questionable, since you’re implicitly taking on responsibility for the contents of the package (or at least nixos is, if you stopped maintaining it). You can’t vouch for something you haven’t tested, and future versions with arbitrary user-provided checksums could range anywhere from broken to malware.
This is a solution that is sometimes taken (and there are slightly better places to mirror these kinds of things). I’m not in control of mirrors like that personally, so someone else will have to chime in for assistance with that.
Another option is writing a very smart update script, and rely on that to catch new versions quickly, but that would still result in a package that is frequently broken. I suspect upstream wouldn’t want to merge something like that, so a flake with an entry in the wiki would probably be a better option, assuming a mirror isn’t an option.
Finally, just a wiki page documenting exactly how you got it to run might not be too bad.
Also, as a reminder, make sure to double check the WebEx licensing situation; I assume you have, since you’re packaging it, but it’s not uncommon for software like this not to permit redistribution - which would make both packaging and re-hosting a problem. Packaging would still be possible, but you would have to explicitly make the user download the .deb themselves, like some packages do (notably Oracle jdk). You’d still have a problem with the checksum, of course.
requireFile is your friend here. Look at how it’s used for Citrix as an example. You will (most likely) not be able to distribute the actual .deb for licensing reasons.