Details: I installed rak_common_for_gateway 4.2.0 several months ago, configured it, and have been running just the ttn-gateway periodically since then, as I was learning the system. I’m preparing to do some development now and want to update to 4.2.3.
But I don’t see an easy way to do updates. If I clone 4.2.3 into a new directory and configure and install it, I presume it will overwrite the current (running) 4.2.0 version (meaning that I’d have to re-run the configuring programs again and re-install any changes I made).
I’ve done a “diff -r” on the 4.2.0/ and 4.2.3/ git clone directories, and the result is pretty long. But I think the changes I want are actually in the /opt/ttn-gateway/ directory that the install procedure creates, anyway, so the patch file that would result from the “diff -r” wouldn’t be useful anyway.
Am I missing something? Is there an easy way to apply ongoing RAK patches to the current, running gateway system so that I can keep the system up to date without doing a complete reinstall and reconfigure?
If not, is this the best way to do it, taking care along the way to back things up and check the results of each step before proceeding?
This is the upgrade log of rak_common_for_gateway, We can see that they did not update the lora function, but added some support for the new lora module.
For RAK2245, V4.2.0 and V4.2.3 are almost unchanged.
I’ve made some changes to the source code for the gateway, and I’ll be making some more. I’m trying to figure out if there’s an easy way to preserve my configs, apply RAK patches to the code base (e.g., 4.2.0 --> 4.2.3) and then apply my changes over those, recompile and install, and restore my config files. The RAK install process (git clone, ./install.sh; resulting production system in /opt) complicates things.
The RAK code seems pretty stable, but I expect there will come a time when I’ll need to install an upgrade. I thought that successive diffs and patches from the install tree might do it, but I haven’t worked through it yet. I was trying to work through the process before I make many more changes in the base code.
I’m increasingly thinking that this will be a manual process.
At some point in the next couple of months I will be looking at the upgrade path - which I’m anticipating will be mostly about preserving the config and allowing the newer code base to overwrite the older (after a backup). The gateway is relatively stateless, that is, it doesn’t need to hold information like the last frame counter or any of the keys, so I see no reason why this wouldn’t work out.
In the meanwhile, I’m just doing the equivalent of a new install.
