Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> 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.

View on HN

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).

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.

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...

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.

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.

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?

I admit that NixOS doesn't make these, advanced-but-useful tasks particularly easy. NixOS's design has only gotten as far as making these tasks possible, which is still an improvement over the state of the art at the time.

Not only a new language, but one that, once in use, doesn't really look like something built for this purpose, if that snippet's representative. That is ugly.

Any other package manager has config files which are essentially a domain-specific declarative language.

Sometimes to do a whole new thing, you have to learn a whole new language.

What would the Debian way to do this be? I bet it would take more than six lines of code.

Edit: I was wrong, the patching part at least is not too bad on Debian: https://unix.stackexchange.com/questions/324680/how-to-apply...

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.

I'm thinking about trying. I also think it should be logging to syslog so people can actually figure out why it's this way.

That definitely sounds like a useful feature, do you think upstream would reject that too?

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.

Reply on news.ycombinator.com