After updating my system today, I noticed that gnu-netcat suddenly showed up in my installed AUR packages. I definitely didn’t install it myself, and I can’t figure out where it came from. On the AUR page it says:
Dropped this to the AUR from the official repos due to https://gitlab.archlinux.org/archlinux/packaging/packages/gnu-netcat/-/issues/1, it is not considered maintainer and you should most likely be using openbsd-netcat instead :)
Does anyone know if this is something Garuda includes by default, or could it have been pulled in by another package?
I think we should force the replacement, otherwise a lot of folks will unknowingly install the AUR package next time they update. It’s not going to break anything, but I think it is an undesirable outcome.
I’m a bit curious — how does garuda-update ensure that gnu-netcat is only replaced with openbsd-netcat once, instead of doing the replacement on every update?
I’ve added a new “intervention sequence” that gets stored to disk at /etc/garuda/garuda-update/intervention_sequence. The intervention sequence is a number that starts at 0 and every time we add a new check it will be increased by one. (The current target intervention number is 1, but in the future it will be higher).
I’ve summed up all of garuda-update’s existing interventions (of which there are a lot, but none of them will ever trigger again because the issues they were designed to solve are already long gone on an updated system) plus this new intervention into intervention sequence number 0.
When a garuda-update finishes successfully, that means the interventions of intervention 0 were successfully applied. Then, garuda-update saves the number 1 to the intervention sequence file, meaning all interventions of number 0 are skipped automatically, reducing not only processing time, but also preventing the package from being replaced once again. Ancient installations of Garuda Linux will still benefit from the old interventions, while newer installations will not have to carry them around any longer.
This is very similar to how garuda-migrations handles non-package related migrations (usually for config files).