LibreOffice re-using Mozilla's MAR-based updating functionality

Developer Community
#1

Hi all, this is mostly a heads-up (and a few questions), but I’m also interested in whatever helpful comments you will have. I’m cc’ing @bhearsum as he offered support in the past (in a comment at https://bugs.documentfoundation.org/show_bug.cgi?id=68274#c45 “provide better update mechanism – Mozilla ARchive (mar) based incrementals”).

The current LibreOffice (LO) approach to updating (mainly for macOS and Windows, as Linux is typically served by distros) is mostly manual: LO can periodically check a server for new releases, and announce them to the user, and potentially even automatically download them (as macOS dmg or Windows msi files), but leaves actual installation of the new release to the user. Besides that, there had also been some off-by-default MAR-based functionality integrated into LO quite a while ago, but it never went anywhere so far. As an alternative to LO’s traditional updating approach, it would periodically check a server for new mar files, download them, and automatically apply them on the next start of LO.

I have now taken on the job of resurrecting that code in LO and making it work on Windows. As a first step, I disentangled the original Mozilla code and any LO-specific modifications, and upgraded the Mozilla code to a recent upstream state. (The main result so far can be found at https://git.libreoffice.org/core/+/3a445cb49795fabe0d8caaf12bfc38eb9e12d5fc^! “Turn onlineupdate into external/onlineupdate”.)

Question 1: For now, I’m picking the relevant Mozilla code, somewhat arbitrarily, from a recent https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f (“Bug 1867784 - Force reflow all kids in the last column balancing reflow. r=layout-reviewers,dholbert”) trunk state. I didn’t find any tag or branch in that github repo that immediately suggested itself to me as a useful “latest stable version” from which to pick instead. Any suggestions?

With that, I’m seeing LO find and download a hand-crafted mar file (containing just a program/version.ini file with a modified buildid) from a local test server, and invoke the MAR updater.exe to apply the mar file (replacing LO’s program/version.ini file in-place, in a user-writable LO installation), and restart LO.

For Windows, there is also the MAR maintenance service that would allow to modify a non–user-writable LO installation. I’m also building that, but haven’t seen it in action yet.

Question 2: Is there any guidance how to see that maintenance service in action with my above test scenario? I got lost in Mozilla’s toolkit/mozapps/update/updater/updater.cpp, trying to understand under what circumstances the code would defer to that maintenance service instead of doing the modifications all by itself.

Question 3: The original Mozilla maintenance service is recorded in the Windows registry under a MozillaMaintenance key. The service I’m building as part of LO should be functionally identical to the original Mozilla one. I could either record it under its own key (LibreOfficeMaintenance, say), or keep the original name. In the latter case, on a machine where both Firefox and LO are installed, a single version of the service would be kept, whichever of the two installations brings the more recent one. Any thoughts on this?

Thanks, Stephan

#2

Got that part now. What I missed initially is that there is code in toolkit/mozapps/update/UpdateService.sys.mjs that does write the relevant pending-service token into the update.status file.

#3

Question 1: For now, I’m picking the relevant Mozilla code, somewhat arbitrarily, from a recent https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f (“Bug 1867784 - Force reflow all kids in the last column balancing reflow. r=layout-reviewers,dholbert”) trunk state. I didn’t find any tag or branch in that github repo that immediately suggested itself to me as a useful “latest stable version” from which to pick instead. Any suggestions?

That should be fine. The master branch of that repository tracks mozilla-central, which is where Firefox Nightly is built from, and almost always in a good state. (We have a separate branch where integration happens.)

Question 3: The original Mozilla maintenance service is recorded in the Windows registry under a MozillaMaintenance key. The service I’m building as part of LO should be functionally identical to the original Mozilla one. I could either record it under its own key (LibreOfficeMaintenance, say), or keep the original name. In the latter case, on a machine where both Firefox and LO are installed, a single version of the service would be kept, whichever of the two installations brings the more recent one. Any thoughts on this?

Please change the name. For both the sake of LibreOffice & Firefox I don’t think it’s a good idea to assume that they can be shared. (Eg: if we make some breaking changes to how it works, it may break you when we roll them out.)

#4

Thanks. By the way, is there some channel I should be subscribed to, to learn early about upcoming changes in that area of the code?

#5

…ideally, security-related issues, even?

#6

There’s no mailing list or anything like that, unfortunately. The best suggestion I can give you is to watch the “Toolkit: Application Update” component on bugzilla.mozilla.org (https://bugzilla.mozilla.org/describecomponents.cgi?product=Toolkit). All of the core update work in Gecko ends up there. (Some of the Firefox specific UI surface ends up in other components - but I don’t think you’d be interested in those anyways.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1799332 is one upcoming thing that is changing things significantly on macOS.