Add SoftwareUpdater

[scottmc]

Some work has started on this. This would be a nice to have feature for Beta1.

​http://cgit.haiku-os.org/haiku/commit/?id=b4ad45f630a45db4043ff5d062fcddb84652585d

From the kallisti5 on the Haiku dev mailing list:

This was a quickie job and the meat + potatoes calls to the Package Kit still need done. Any help with adding the translation stuff would be awesome :-)

​https://ibin.co/34oymHEemyvY.png

Btw, my workflow plan currently for this stuff is:

1. A Notification pops up (​https://ibin.co/34nmgIhhc3VH.png)
2. If the user clicks it, the notification launches SoftwareUpdater (​https://ibin.co/34oymHEemyvY.png)
3. Things happen (tm) and maybe update a listview of packages getting updated?
4. Profit.

[diver]

Maybe perelandra is interested since he worked in a related area recently?

[vidrep]

"Things happen (tm) and maybe update a listview of packages getting updated?"

This is something that's definitely needed, since the end user wants some control over which items are updated, particularly when there are regressions. Perhaps a checkbox and content view similar to expander?

[perelandra]

Probably the "meat" would need to be a derived BPackageManager class like what pkgman does here: ​http://cgit.haiku-os.org/haiku/tree/src/bin/pkgman/PackageManager.cpp

Just replace all the stdout just with GUI alerts or dialogs.

Of course a very simple 0.1 version could just open a terminal window and run 'pkgman update -y' :-)

[perelandra]

kallisti5,

I just started looking at the SoftwareUpdater code and it looks like we are thinking along the same lines. Just change the printfs to something that will modify the window's string views. To kick off the process in the window's _Refresh() function you should be able to use this code as a template: ​http://cgit.haiku-os.org/haiku/tree/src/bin/pkgman/command_update.cpp#n102

I'd be happy to help out with this.

[perelandra]

I have been working on a new notification center but I am almost ready to take a break from it for a while and work on something else. Want me to take a look at this?

I think kallisti5 has a great start here. There is only one window so far but I think to make a basic updater (no options to choose which packages to install, it's all or nothing):

-Initial info window that there are updates available (done). -Window showing a list of the available updates, buttons to Cancel or Update All -Problem handler window. I saw an example of this recently in HaikuDepot with a package that was built incorrectly. Might be nice to "borrow" that class :-) -Progress status window, could be just a line or two of text. Would show the package name currently being downloaded and percent complete, and then final actions being done to complete the process. -Final status window, shows completed status of update and if it was successful buttons to reboot now or later.

With these multiple windows the main working code should be in its own thread to kick off the UpdateManager. The UpdateManager can send messages with status updates for each window to update its text.

[humdinger]

Sounds like a plan, I'd say go for it!

One thing though, that "reboot now or later" button. I expect the Updater checks for updates in all active repos. Can you differentiate updates of packages that require a reboot (core Haiku) vs. trivial updates of some app?

[perelandra]

Hmm, that's a good point. I'd have to check the code to see if there is a way to see at the end which packages were updated from the Haiku repository. What happens though with other 3rd party packages that may be running and you update them? For example if I have ClipDinger running and update its package, does the currently running instance of the older version continue running until I either restart the app or reboot the system?

[humdinger]

I'd expect the currently running (outdated) app will continue running. Not sure what'll hppen if it's closed and restarted...

I think I'd just play it safe and vague: "Some updates may require a restart." Button: "Restart now", "Don't restart".

[pulkomandy]

Detecting what comes from the haiku repo is not enough, for example if you update the system fonts, things can go pretty bad at the moment. There can also be problems with updating some libraries (freetype, or libpng, for example). You could detect that anything that the Haiku package depends on is updated, and more stringly suggest a reboot in these cases. But still suggest it (weakly) in other cases, because you never know.

[axeld]

Don't we know if the state could be applied or not, and only offer a reboot if it couldn't be applied yet? IIRC pkgman does print such a message.

[perelandra]

Replying to axeld:

Don't we know if the state could be applied or not, and only offer a reboot if it couldn't be applied yet? IIRC pkgman does print such a message.

It doesn't. This is after updating from hrev50900 to 50901:

[system] Applying changes ... [system] Changes applied. Old activation state backed up in "state_2017-01-25_14:14:50" [system] Cleaning up ... [system] Done.

[perelandra]

I've been poking around the code for package management, HaikuDepot and the package daemon and I am thinking the best option may be to integrate it right into HaikuDepot from the start. There are already classes for a GUI enabled PackageManager, problem solver window, results window (some of these are actually from the daemon). The current HaikuDepot PackageManager uses a PackageAction class to do the current install/uninstall of individual packages. It is designed around acting on only a single package (plus its dependencies) but I think it should be possible to expand the PackageManager class slightly to add functionality to use an UpdaterAction class that updates multiple packages.

Maybe someone like Ingo with more knowledge about these things can chime up. It looks like the HaikuDepot PackageManager class was a copy/expansion of the package daemon's class and I could also take the same approach and create another "fork" of it, however that now means there would be 4 PackageManager classes (that I know of, also pkgman has one) and more duplicate code that would need updating if package management changes in the future. I'd rather tie into what is already in HaikuDepot if I can.

[pulkomandy]

Integrating in HaikuDepot sounds fine. An alternative is moving the code to either libpackage (if it is really generic) or libshared (if it is not really generic, but still shared by some of our apps).

[waddlesplash]

Yeah, integrating with HaikuDepot seems the best option.

[perelandra]

I have been working slowly on this, time has been limited for me lately but I do have it performing updates, sending text updates to the status window and using the status window for prompting the user. I decided not to expand the HaikuDepot PackageManager because it was built around the task of installing only one package and the workflow didn't really fit well with doing updates of multiple packages. Instead I am building upon the pkgman PackageManager. As I complete functional pieces I will update my git: ​https://github.com/Perelandra0x309/haiku/tree/updater/src/apps/softwareupdater

[Giova84]

With the commit a4655eb8f9abab427710bc3c690ff7f43f1f2dce - on hrev51122 - SoftwareUpdater has been added to Haiku by default.

Many thanks to Perelandra for his work!