Lucifer06 / RemoteGPIO

Remote General Purpose I/O for Venus OS devices (Cerbo GX, ...)
13 stars 4 forks source link

SetupHelper conflict resolution enhancements #15

Closed kwindrem closed 8 months ago

kwindrem commented 8 months ago

I've enhanced SetupHelper's conflict notification and resolution mechanisms. Lots of changes to PackageManage and it's menus.

Please look it over and let me know if you find any issues (or that you didn't find any). Thanks.

kwindrem commented 8 months ago

One comment: hiding the GUI restart and reboot messages by pressing "Later" is set to 5 seconds for testing. I'll increase that to 10 minutes after testing is complete.

Exiting the package edit menu and reentering it will reset the timer as well changes to the need action (from GUI restart to reboot for example).

Lucifer06 commented 8 months ago

Nice work. I like the possibility to restart PackageManager service. I also tried the conflict resolution. For example to install latest Guimods that was conflicting with RemoteGPIO3.0.23 (because of MbItemDigitalInput.qml), It correctly uninstalled RemoteGPIO, then I could install GuiMods. But then I faced issue #2 below.

Two issues: 1/ Randomly I see that the menu Download is disabled while it should not. I see this behaviour for a while, even before I moved to your SetupHelper beta branch. In order to fix the issue, I simply go one step back and return to the package. Not a bid deal ;-) Capture d’écran 2024-03-11 à 10 29 12

2/ I have faced a situation where RemoteGPIO was not showing latest GitHub version. I don't know how often you pull Github, but I would suggest that a restart of PackageManager service should trig this refresh. Capture d’écran 2024-03-11 à 10 34 31

I have then tried removing RemoteGPIO and adding it again, and now it doesn't anymore display any GiHub version. Capture d’écran 2024-03-11 à 10 42 51

A reboot doesn't fix the issue.

Then I tried to resolve the the package conflict from RemoteGPIO package page, that was at this stage uninstalled. It offered me to remove GuiMods v10.9, which I did. But then still could not download latest RemoteGPIO as it's not listed... Capture d’écran 2024-03-11 à 10 53 30

The button to resolve package in RemoteGPIO is again here, but this time it offers me to resolve the conflicts by installing GuiMods. It did it, but that didn't helped.

I'm afraid, I'm stuck in a dead loop because of previous conflict....

Lucifer06 commented 8 months ago

Argh, I must be tired, there was a typo in my branch, this is beta-3.0, not Beta-3.0 :-((((

Anyway I think I went lost with above issue because at some points both remoteGPIO and GuiMods where saying there was a conflict. This is probably because of my particular situation that got both installed and updated PackageManager that handles conflicts only after.

Lucifer06 commented 8 months ago

So more likely forget about issue #2 reported above

kwindrem commented 8 months ago

I have seen the missing download button and will look into that.

There are two parts to conflict resolution: One checks the packageDependencies file against which packages are installed or not. The other checks files this package would install against which package previously replaced it. If the previous package is not this package a conflict is raised. The dependency part showed a conflict for GuiMods not being installed while the previous package for MbItemDigitalInput.qml was the conflict reported if GuiMods was installed.

GuiMods most would have reported a conflict based on MbItemDigitalInput.qml being installed by RemoteGPIO. That might have occurred if RemoteGPIO was installed with GuiMods not installed and while MbItemDigitalInput.qml was still installed by RemoteGPIO. That's a nasty state to be in since I'm not sure how someone could resolve it. Something else for me to ponder.

kwindrem commented 8 months ago

Your GitHub version problem was caused by the incorrect branch/tag entry but it got me thinking:

GitHub version information is refreshed when entering the Active packages menu. It's also refreshed for one package when entering the Package editor menu or when doing Previous / Next. Version info expires 10 minutes after its last refreshed. If automatic downloads are enabled, the refresh also occurs every 10 minutes.

Sitting in the Active packages or Package editor menu for more than 10 minutes with automatic downloads turned off would cause version info to disappear. Plus, the versions could change sooner than that. For manual operations, I think a refresh every minute is indicated and I'll add timed refreshes in these two menus.

Thanks for your input and for your testing. Two minds are better than one.

kwindrem commented 8 months ago

I have made substantial changes to the way GitHub version information is refreshed. I think all is well now. I refresh versions automatically now while in the Package editor and Active packages menus.

The GUI requesting version refreshes was at least one cause of Download, Install and Uninstall/Remove buttons being disabled. Somehow I was hanging dbus updates to the shared parameter I use to synchronize operations between the menu and PackageManager.py. That's fixed also now.

Lucifer06 commented 8 months ago

Sounds good. Are you releasing all these changes on the main branch?

kwindrem commented 8 months ago

Yes, I plan to release it in a day or so but want to a little more testing.

Thanks for your efforts.