← Back to context

Comment by zozbot234

3 years ago

> and refuse to allow it to be disabled

Why don't people fork these terribly managed projects? Even just working on the feature and then submitting the .patch file to be merged in by downstream distros would be a very meaningful signal.

14 comments

zozbot234

Reply
grumbel  3 years ago

Big problem is that just forking it isn't enough, you also have to convince every distro out there to switch to your fork to make any real difference. It becomes a truckload of boring work for what might be a trivial one-line fix in the code.

I blame the package managers we use for this, as most of them make it incredible difficult to change anything and make you a slave to whatever the distribution ships, which in turn is slave to whatever upstream ships. The effort to fix the issue just far outweighs the issues the problem is causing in the first place.

NixOS is one of the few that seems to get this right by making code changes pretty much trivial. Just fork the upstream repository, point the package to the new fork and you are done. With a Nix flake you can even make the repository itself installable directly. No need to try to convince any maintainer to include your patch. And having package names be hashes means you can switch between old, new and patched versions of a software easily, no need to worry about conflicts or having to un/reinstall all the time. Downside is the lack of binary compatibility in NixOS, meaning if you change a package deep down the dependency tree you might end up recompiling half your distribution and can no longer use the precompiled binaries (there is `patchelf` to workaround this, but haven't used that myself yet).

  • rssoconnor  3 years ago

    Not only can you do that in NixOS, but you can even do something lighter weight and apply a patch to an existing package. This has the advantage that the patch often persists through software updates.

    For example, I used to patch OpenSSH to increase the minimum field size for DH key exchanges [1]. Eventually OpenSSH did update their minimum field sizes so I do not use this patch anymore.

    [1] https://r6.ca/blog/20150111T040537Z.html

    For those interested, patching OpenSSH in NixOS involves adding the following to one's system configuration:

        nixpkgs.config.packageOverrides = oldpkgs: {
      openssh = pkgs.lib.overrideDerivation oldpkgs.openssh (oldAttrs: {
        patches = oldAttrs.patches ++ [ ./openssh-dh-grp-min.patch ];
      });
    };

    where openssh-dh-grp-min.patch is the patch file you want to apply.

    • AnIdiotOnTheNet  3 years ago

      Man, NixOS would probably be a lot more useful if people didn't have to learn a whole new goddamned language to use it. I realize making some kind of discoverable and sane interface to the this is probably not trivial, but is it really so impossibly difficult that no one involved with the project wants to do it?

      3 replies →

  • zozbot234  3 years ago

    Debian-based distros make it easy to rebuild .deb's with extra patches. Source package management and build-time dependency tracking is integrated in the package manager, so it's just a matter of downloading the source, adding your own .patch file and rebuilding.

    • grumbel  3 years ago

      I wouldn't call that easy. Downloading source, doing a patch and rebuilding once is doable[1] with some manual work. But even that doesn't last, it's extremely brittle the moment you try to update anything. Debian isn't build with forks in mind, it wants one big monolithic dependency tree and when you move away from that it falls apart quickly. Which is the reason why they recommend to remove all third party stuff whenever you do a dist-upgrade.

      [1] https://unix.stackexchange.com/questions/324680/how-to-apply...

      1 reply →

    • coryrc  3 years ago

      That's what I did, it was pretty easy. Apt got the build dependencies for me, I just had to make the code change and dpkg-buildsomething made it, and then dpkg -i.

      Luckily I don't update often and this package should be forward compatible for a long time given the slow rate of change.

  • pabs3  3 years ago

    The patch looks pretty simple and is in a part of the code that probably doesn't change much, I bet it would be possible to get it included in several distros.

  • flyinghamster  3 years ago

    Ansible can also come in handy for changing irritating defaults or substituting packages. If I'm setting up a plain Debian desktop, it makes it nice and quick to rip out Firefox ESR and grab the non-ESR Firefox from Sid.