Interim fix for old firmware version requests, attempt 2
Regarding #400 and #398
Never commit when tired and distracted.
As before, fixes rnodeconf not looking for hashes for --fw-version requests. Automatically fails the unsigned.io request due to always returning the latest version hash and falls back to GitHub.
Tested with 1.65 (outdated) and latest (without using --fw-version) using a LilyGO board.
Thanks for this PR, btw. I haven't had time to look at it yet. I will when I can, but it will be a little while.
It's an edge case, and there's a solution on the books, so to speak, if someone needs it fixed today. Honestly, the need to use a non-local repository for an old version is not exactly common. It might need conceptual tweaking and better integration with unsigned.io anyway.
I really appreciate the effort on this fix, but I've been thinking a bit about the overall picture regarding this functionality, and realistically, we need to do a bit of rearranging to properly implement this functionality. It needs additional setup on my firmware server, and unfortunately I can't prioritize this at the moment.
As also mentioned elsewhere, I think the best course forward would actually be to overhaul the install and firmware hosting system quite a bit, which could clean up and make the install and hosting process a lot easier.
I've also talked a bit with @jacobeva about this, and what I'd ideally like to see is a system that:
- Will have a default firmware repo source for the base boards and configurations supported in the main repo
- Will let users easily add other repositories that can serve as sources for other kinds of boards and devices, provided by the community, individuals or vendors
- Allow users to more easily install, provision and configure boards
- Maybe even have the ability to self-serve a web-based installer
All of this is beyond my ability to work on at the moment, but if the community wants to take it up, I would fully support that :)
In general, I think this is a great point in time to give over more of the ownership and control of the RNode project to the community, given that there are people who actually want to take on some of the responsibility for keeping the project alive and available. It seems like this is the case presently, and I think this is would be a good way to do it :)
Maybe this thread should have been moved to a discussion, or a new one created for better visibility, but here it is. Feel free to trail it off somewhere else too.
Also pinging @ahedproductions on this, since you might have interest in this part of the project too.
I was working on leveraging the lessons learned from POPR to make a Reticulum request/resource-based firmware provider. While that may not be exactly what we're looking for vis a vis RNodeConf as a whole, setting it up as a library so people can set up their own repos (but having a default set of mirrors) addresses two desires of "updating the repository server" and "using Reticulum to deliver the firmware."
I expect it to be a fairly quick project, and would be happy to adjust it to the needs of the wider firmware configuration system.
I think that's a very good excercise, and would move us closer to a good system. Ideally, I'd also love to have it all running over Reticulum, instead of HTTP. Forgot to add that to the list up there ;)
Mike that sounds like a great project! Keep us updated in the Matrix channel please, I very much look forward to such a tool. I cannot currently assist with development as I'm bogged down with work, but I will most definitely help with testing in the future :)