Can confirm. Found that out today also by accident.

(In reply to Olivier Hallot from comment #0)

See Mike's comment on see also/dupe bug 160585 and bug 68274

> 
> Note: The update was in 2 steps, no indication why, which I gess it is for
> the main software and the Help. A more verbose text is welcome.
> 

Believe that is expected, the MAR packaging is specific to signature, i.e. from 24.8.2.1 --> 24.8.3.1 --> 24.8.3.2

I can confirm as well. As a user, I would expect the version to be the current one after the update.

I can confirm in Windows 11 as well.

*** Bug 160585 has been marked as a duplicate of this bug. ***

*** Bug 166476 has been marked as a duplicate of this bug. ***

A MAR update 25.2.4.2 -> 25.2.4.3 just rolled [1]. And I got a nice notification via webpage opening "You have updated to LibreOffice 25.2.4".

But, still no update in appwiz.cpl to Windows registry of installed build string, so while this was an install with the 25.2.4.2 by MSI--the install is drifting from registry and subsequent management by MSI.

Is there nothing in now automated (when built and released by TDF) for the MAR incremental patching that can update Windows registry?


=-ref-=
[1] snip from the updateing.log

Update Check Time: 53478310
Update check: https://update-mar.libreoffice.org/update/check/1/LibreOffice/508ff62361999404a9d3590fe47df713b5888744/Windows_X86_64/LOOnlineUpdater
Download: https://update-mar.libreoffice.org/update/check/1/LibreOffice/508ff62361999404a9d3590fe47df713b5888744/Windows_X86_64/LOOnlineUpdater
Download File: https://update-pool.libreoffice.org/25.2.4.3/LibreOffice_25.2.4.3_Windows_X86_64_33e196637044ead23f5c3226cde09b47731f7e27_from_508ff62361999404a9d3590fe47df713b5888744_partial.mar; FileName: update.mar
Download: https://update-pool.libreoffice.org/25.2.4.3/LibreOffice_25.2.4.3_Windows_X86_64_33e196637044ead23f5c3226cde09b47731f7e27_from_508ff62361999404a9d3590fe47df713b5888744_partial.mar
TempFile: file:///C:/Users/vsfoote/AppData/Local/Temp/lu11040vu84d.tmp/lu11040vu84f.tmp
Destination File: file:///C:/Users/vsfoote/AppData/Roaming/LibreOffice/4/updates/0/update.mar
Calling the updater with parameters: 
Patch Dir: C:\Users\vsfoote\AppData\Roaming\LibreOffice\4\updates\0
Install Dir: C:\Program Files\LibreOffice
Working Dir: C:\Program Files\LibreOffice
soffice Path: C:\Program Files\LibreOffice\program
Removing: file:///C:/Users/vsfoote/AppData/Roaming/LibreOffice/4/updates/0/update.mar

(In reply to V Stuart Foote from comment #7)
> Is there nothing in now automated (when built and released by TDF) for the
> MAR incremental patching that can update Windows registry?

No there is nothing (unless we are willing to mess with the Windows Installer-managed registry settings, which IMO is not a nice thing to do).

We are destined to have this kind of problems, if we mix two installer technologies that aren't designed to cooperate.

(In reply to Mike Kaganski from comment #8)
> No there is nothing (unless we are willing to mess with the Windows
> Installer-managed registry settings, which IMO is not a nice thing to do).

Well, it would only update the version number field and simply remove the version number from the name field. Mozilla is acting no different at this place, and we're actually using their system... everything would actually still the same in that list / registry entries.

(In reply to Dennis Roczek from comment #9)
> (In reply to Mike Kaganski from comment #8)
> > No there is nothing (unless we are willing to mess with the Windows
> > Installer-managed registry settings, which IMO is not a nice thing to do).
> 
> Well, it would only update the version number field and simply remove the
> version number from the name field. 

Well maybe could write the string for DisplayName and DisplayVersion, but could be more troublesome.

> Mozilla is acting no different at this
> place, and we're actually using their system... everything would actually
> still the same in that list / registry entries.

Except that Mozilla uses an .EXE installer and lays down links in registry to its uninstall\helper.exe and a full key for its uninstalls.

And other than the Display Name & Version, the LibreOffice MSI based install uses a GUID ProductID that is unique for each LO build. The ProductIDs between release builds will not match, e.g.

25.2.4.2 is {8E3F0870-B678-46C6-A14C-069F300ABD41}
25.2.4.3 is {E67DBA3B-4C2A-44AC-BC4D-86EA56550BB3}

The MSI installation *and uninstallation* explicitly use the ProductID!

Effectively, after the MAR update(s) apply, the appwiz.cpl uninstall can fail as components associated with the ProductID are not correct in the Windows registry.

At present you almost have to install the MSI package to bring the registry up to matching release level to be able to uninstall a MAR updated instance *reliably* using the appwiz.cpl--or risk leaving more "garbage" behind in FS and the Win registry. Leading to dependency on utilities like revo or ccleaner.

*** Bug 167078 has been marked as a duplicate of this bug. ***

As "V Stuart Foote" explained already, mixing two different installer-technologies is ... not the best ... idea :D

So, in the long term, moving away from MAR to an MSP-based (MSI Patch) approach would be welcome. And Yes I know, that would make a lot of time invested into the MAR thing obsolete :(

Of course you could also move away from MSI for Installation at all. But then Businesses will go nuts, because many rely on MSI-Packages for Application roll-out and -update.

In the short term, I doubt that changing "DisplayName" and "DisplayVersion" in the registry by the MAR-Updater makes the situation worse in terms ob being able to uninstall/repair an LibO-MSI-Installation. As the field-names say, those are for Display :D 
BUT having the right version-information in those two fields, would make 3rd party Software-Update Tools that rely on the registry, like Kaspersky, uCheck, aso. to not give the users false positives. Currently those apps tell the user that LibreOffice needs to be updated, even though in reality it was already updated by MAR. So I think on the short term, making the Updater patching those two registry values would be a benefit.

BTW: Is there a group-policy or another "comfortable" was to disable the MAR-Updater in Domain-Environments? So far, I have to patch XML-Files via scripts, which is not so "elegant" :D

Thanks for clarifing. I should have verified that before, but using windows to seldome nowadays.

(In reply to V Stuart Foote from comment #10)
> (In reply to Dennis Roczek from comment #9)
> > (In reply to Mike Kaganski from comment #8)
> > > No there is nothing (unless we are willing to mess with the Windows
> > > Installer-managed registry settings, which IMO is not a nice thing to do).
> > 
> > Well, it would only update the version number field and simply remove the
> > version number from the name field. 
> 
> Well maybe could write the string for DisplayName and DisplayVersion, but
> could be more troublesome.

Well, I think we should simply drop the Versionnumber at all from the DisplayName. No other software does this except DotNetRedistr or other libraries by MS or other major software without an autoupdater or the like.

> > Mozilla is acting no different at this
> > place, and we're actually using their system... everything would actually
> > still the same in that list / registry entries.
> 
> Except that Mozilla uses an .EXE installer and lays down links in registry
> to its uninstall\helper.exe and a full key for its uninstalls.
Ah, yes, I forget this. To seldom need a new install.

(In reply to bugzilla2 from comment #12)
> As "V Stuart Foote" explained already, mixing two different
> installer-technologies is ... not the best ... idea :D
> 
> So, in the long term, moving away from MAR to an MSP-based (MSI Patch)
> approach would be welcome. And Yes I know, that would make a lot of time
> invested into the MAR thing obsolete :(
> 
> Of course you could also move away from MSI for Installation at all. But
> then Businesses will go nuts, because many rely on MSI-Packages for
> Application roll-out and -update.

In this case I would wait without investing too much time on this ticket, because MS announced recently the opening of Windows Update for 3rd-party software. I still remember their (MS Win Core team) long explanation to the start of Win10 why they believe, that providing any auto uodater base is a bad idea... 😂

From start, we needed to not look for any minimized patches, be it MAR or MSP. We needed to just make normal MSI installs, just make them automated. And focus on making them reliable (i.e., tdf#117492). The whole minimal patch idea will be nothing except burden on everyone, and a source of endless problems.

(In reply to Mike Kaganski from comment #15)
> From start, we needed to not look for any minimized patches, be it MAR or
> MSP. We needed to just make normal MSI installs, just make them automated.
> And focus on making them reliable (i.e., tdf#117492). The whole minimal
> patch idea will be nothing except burden on everyone, and a source of
> endless problems.

I hate inefficient software. I hate monster downloads, cpu load, gpu load, bloat software although having a good line or 5G on the road. It is more a matter to iron out problems. And yes this always needs adaprion for os changes and is not easier than simply distribute and fresh install LibreOffice. Actually FOSS is also a show case of doing it better than many properterian vendors with the help of the crowd (commericial or volunteer or whatever).

Still, we have a working system for most users and I fould wait on focus on MS new system which hopefully resolves problems by the time.

Believe what you like, and prefer software made to please one's sense of beauty over made robust. From my side, I stop caring about MSI part of LO.