Opened 4 years ago

Closed 3 years ago

#13187 closed enhancement (fixed)

Add SoftwareUpdater

Reported by: scottmc Owned by: perelandra
Priority: normal Milestone: R1/beta1
Component: Applications Version: R1/Development
Keywords: Cc: perelandra
Blocked By: Blocking:
Platform: All


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

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 :-)

Btw, my workflow plan currently for this stuff is:

  1. A Notification pops up (
  2. If the user clicks it, the notification launches SoftwareUpdater (
  3. Things happen (tm) and maybe update a listview of packages getting updated?
  4. Profit.

Change History (18)

comment:1 by diver, 4 years ago

Cc: perelandra added
Component: - GeneralApplications

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

comment:2 by vidrep, 4 years ago

"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?

comment:3 by perelandra, 4 years ago

Probably the "meat" would need to be a derived BPackageManager class like what pkgman does here:

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

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

Last edited 4 years ago by perelandra (previous) (diff)

comment:4 by perelandra, 4 years ago


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:

I'd be happy to help out with this.

comment:5 by perelandra, 4 years ago

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.

comment:6 by humdinger, 4 years ago

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?

comment:7 by perelandra, 4 years ago

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?

comment:8 by humdinger, 4 years ago

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".

comment:9 by pulkomandy, 4 years ago

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.

comment:10 by axeld, 4 years ago

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.

in reply to:  10 comment:11 by perelandra, 4 years ago

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.

comment:12 by perelandra, 4 years ago

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.

Last edited 4 years ago by perelandra (previous) (diff)

comment:13 by pulkomandy, 4 years ago

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).

comment:14 by waddlesplash, 4 years ago

Yeah, integrating with HaikuDepot seems the best option.

comment:15 by perelandra, 4 years ago

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:

comment:16 by pulkomandy, 4 years ago

Owner: changed from kallisti5 to perelandra
Status: newassigned

comment:17 by Giova84, 3 years ago

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

Many thanks to Perelandra for his work!

comment:18 by scottmc, 3 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.