Arch Linux

I'm not sure why this is supposed to be so complicated.

Arch Linux follows upstream. We do not tend to patch software unless the patch is an upstream patch that was accepted by the project's upstream, but not yet released. If upstream has not approved a change, we need some *really* compelling reasons to make that call ourselves.

It adds maintenance burden to our packages, compromises our KISS principles, and results in software that does not behave the way upstream expects it to.

In this case, upstream has seen the proposal and has emphatically said "hell no". That's the end of the discussion. Bug rejected, appeal to reopen rejected rejected rejected and rejected again.

Let's add to that some case-specific details: some portion of the upstream developers don't just say "no", they say "I regard this change as an illegal violation of my copyright". Your politically motivated desire to just use zfs at all costs is insufficient grounds for actively picking a legal fight with upstream.

The zfsonlinux project has resigned itself to not using those functions. There have been suggestions in the community that the zfsonlinux project should never have ever ever used those functions, because using the functions may well be much slower and less performant (or at least more dangerous to stability) than using the kernel's preferred mechanism for such things, which is a userspace helper program.

So you want us to revert upstream changes for no solid technical reason and really, really bad (possibly illegal) political reasons, in order to better support a thirdparty module that we don't even officially support in the first place? What, because NixOS does something stupid we're obligated to do the same?

This opens up a more interesting, general question. Who is responsible to fix software when it breaks -- the developers of the software, the additional software that said software depends on, or downstream distributors of one or the other software? The famous, famous case study in why it is MORONIC for distros to take this on their on shoulders is, of course, the Debian OpenSSL fiasco: https://www.links.org/?p=327

Even if we wanted to patch the linux kernel for the sake of a speed optimization in specific use cases of some unofficial zfs package, we wouldn't do it, simply because it would engender a culture where it is "okay" to patch software just because we disagree with it. And that is something that should ideally be done *never*, and in the rare cases where it is done, it should only be done after much thought, engaging in dialogue with upstream to see whether it can be better solved in a central way, and a clear understanding of the benefits doing so will bring. Patching the kernel for openzfs only fulfills #2, and only by a technicality.

Now, there have already been three reopen requests, all of which have basically just said "but I want it and feel that Linus Torvalds and GregKH are being meaaaaaaaan to me", and don't actually offer any responses to the reason this was closed, which, may I remind you all, was "If upstream denied it, why should we override their decision?", followed up by "You seem to have mistaken Arch Linux for a distribution that has an *interest* in applying politically motivated downstream patches that upstream has explicitly rejected."

If there are further reopen requests, it might be necessary to suspend accounts. We don't care about repeated attempts to rationalize whether the code will still compile.