I’m unhappy right now and I want some opinions. Yes the title is (kinda) clickbait to get you to read this and share your opinion.
The problem child
Right now, we currently have a package called garuda-hotfixes which is automatically updated before all other packages. This in theory allows us to apply some level of hotfixes in an emergency before further updates are installed.
The thing is, when this package was created, garuda-update wasn’t the tool it is today. Today, the update script can handle almost every scenario, and can and does replace garuda-hotfixes entirely. The package has not received an update in over 3 years, and the only reason I can not give you a precise number is that the repository for pkgbuilds literally didn’t exist back when it was last updated.
The one (broken) case
There is one thing that garuda-hotfixes does that garuda-update can’t. Garuda System Maintenance, our tray background service, is in theory able to show notifications and update garuda-hotfixes outside of the normal garuda-update cycle.
Back then, this was important because the update script was nowhere near as widely used as it is today. It has truly cemented itself as the one go-to way to update Garuda, which was definitely not the case back then. Nowadays, Garuda System Maintenance’s support for updating keyrings and the hotfixes package has fallen into major disrepair. The feature doesn’t work anymore and does nothing but try and fail to update the keyrings when the system is first installed. It needs to go.
Phoning home every 60 minutes
As it stands right now, Garuda System Maintenance phones home regularly to check the forum for new Announcements > Announcements - Maintenance posts to display them to the user. Additionally, there is another phone home happening that checks if any keyring package has been updated in the Arch Linux repository OR if the hotfixes package has been updated. This can be turned off in the Garuda System Maintenance settings.
What I’m planning to do about it
If it’s not clear yet garuda-hotfixes needs to go. I plan on removing the entirety of the keyring and hotfix updating support from Garuda System Maintenance. This also removes a large part of the “phoning home” that is taking place, and more critically, isolates the phoning home to only the Garuda Linux official infrastructure, in this case the forum, to display new Announcements > Announcements - Maintenance posts.
I also plan on ADDING one “phoning home” part to garuda-update. Currently, if anything happens that prevents garuda-update from updating itself, there is nothing we can do to prevent the need for manual intervention. If a large scale change, like a switch to new Chaotic AUR infrastructure was happening, there would be no way to smoothly allow older systems to recover. Any widespread future issues that might affect a large amount of users can not be countered on a distribution wide way.
I intend to add a bit of “phoning home” that only kicks in when Garuda Update fails to update itself. At which point, the script will reach out to the Garuda Infrastructure and see if any hotfixes are available and if those hotfixes apply to the current garuda-update version. If they do, the hotfix script will be downloaded from the Garuda Infrastructure and the user will receive a prompt asking for yes/no consent on executing the code that was downloaded.
This way, if all normal hotfix application methods are working normally, the new “emergency hotfix” system will do nothing at all. But as soon as something disrupts it, the new system is there to take over and help in a way that garuda-hotfixes never could, even in its prime.
Relief.
I’ve been thinking about how to handle garuda-hotfixes for weeks now and I think I’ve finally found something I’m happy with and I even wrote it down for others to read! I want to know if this at all sounds reasonable to you all compared to the old system or if there’s any room for improvement.
