Do we have a policy about contributing to Nixpkgs-specific upstream patching?

Hello, Nixers!

I will start this post with a little story.

When I was porting OpenMSX to Nixpkgs, I was paralyzed by the custom build system they use (namely, a Python script embedded in a Makefile).

As I have low programming skills in order to understand and modify the package by myself, I decided to talk directly to OpenMSX developers via IRC.

I quickly explained a bit about Nixpkgs, and how its idiosyncrasies prevented a successful detection of TCL/TK toolkit. Basically, they were trying to detect tcl script in a default location like /usr/local. Then, they made a small patch in their build system in order to accomodate unusual locations for TCL/TK.

Now, my question is:

How should be our policy of relationship with the upstream about that subject of submitting Nixpkgs-specific patches?

I say this because the unorthodox way Nixpkgs works exposes some “flaws” in their building scripts, as hard-coded paths and tacit dependency assumptions like the ubiquitous which.

In the case above, they patched the source in order to handle our specific distro. I think it would be better if we sent some patches to upstream because maintaining them on our side is a nonsense burden, while those patches could help these upstream developers.

But we need to do it in a way we don’t appear like arrogant ad invasive to them.

I’ve often had positive results in submitting upstream, as long as the fixes help generally and don’t special case Nix. Sometimes it helps to show that a patch has been in use in Nixpkgs for a while to show that it works/is stable/etc.

My experience is that it can take a bit of convincing but generally people are happy when their build system becomes more flexible. Most of the patches are related to source binaries from PATH instead of fixed locations, which also helps with other use-cases such as BSD installations and various sandboxed environments.

1 Like