Unfree + unfreeRedistributable package

I want to submit a package for an unfree library that only allows redistribution of its unmodified binaries. Because patchelf will need to alter the binaries, the licenses.unfreeRedistributable does not seem acceptable. If I use licenses.unfree, then the binaries will be patched on the user’s local machine, which is fine. However, it would be useful to cache the original, unmodified binaries in case the download link disappears or changes. Thus, I was thinking of creating two packages:

  • mylibrary, which would be the package you install that contains the patched binaries. This would have the unfree license applied.
  • mylibrary-dist, a dependency of the former that would only contain the original redistributable files and would have the unfreeRedistributable license applied. The output of this package could be stored in cache.nixos.org.

I’ve not seen this pattern anywhere else, so I’m a bit concerned about polluting nixpkgs with something idiosyncratic.

Another question I have is what would happen if the original download link went down but the output was already cached? Would Hydra ever attempt to build the package again if the derivation never changed?

2 Likes

I think that is a fine idea. Just don’t expose the helper package to the main package set. Instead you can define it internally to the package. That way nothing is bloated and the desired behaviour can be achieved.

I’m not sure about the caching.

Thanks for the reply. I agree that not exposing the inner package would be preferable. Unfortunately, I think I need to expose both of them as top-level packages, otherwise Hydra won’t see/build/cache the inner package, which would defeat the purpose of splitting them to begin with.

Maybe I’m overthinking this and should just not worry about caching.

I’m not sure that is true. It will definitely build it, as it would be a dependency of the actual package. It is possible that it would discard it afterwards, but I don’t think it does any garbage collecting.

IIRC the largest problem (for you) is that ATM Hydra won’t touch even unfreeRedistributable packages.

1 Like

Hmm, I guess the idea is moot then.

The idea of having the src be a download with licenses.unfreeRedistributable and then the derivation itself use licenses.unfree sounds like a reasonable idea. With this setup it might then be reasonable for someone to set up a cachix instance that will cache the download if you’re worried about it (note: I’ve never looked at cachix, I don’t know how to configure it, but worst-case maybe the download artifacts can be published to it manually).