avoid that winget mixed up updates for LibreOffice v. 7.x with the v. 24.x

[useforgh]

Brief description of your issue

winget mixed up updates for LibreOffice v. 7.x with the v. 24.x

what would happen if we would mix up Office 2019 with Office 365 ? The results would be similar.

winget list --upgrade-available (the result is false) Name - - ID - - Update Version
LibreOffice 7.6.6.3 - - - TheDocumentFoundation.LibreOffice 7.6.6.3 - - - 24.2.2.2

correct would be eg. based on the previous version: LibreOffice 7.6.6.2 - - - TheDocumentFoundation.LibreOffice 7.6.6.2 - - - 7.6.6.3

or is it caused by the strange ID? TheDocumentFoundation.LibreOffi

or caused by the name? winget show "LibreOffice 7.6.6.3" = no result winget show "LibreOffice" = shows result of v. 24 this could lead to a wrong match

Steps to reproduce

please follow as described above

Expected behavior

Please follow with your provided winget update information the given rules on https://www.libreoffice.org/download/download-libreoffice/

and please treat the versions separately.

v. 24 is not equal v.7 even a future version v. 25 will never be a v. 8

further infos about the v. 24.2.2 https://download.documentfoundation.org/libreoffice/stable/24.2.2/win/x86_64/LibreOffice_24.2.2_Win_x86-64.msi.mirrorlist

further infos about the v. 7.6.6 https://download.documentfoundation.org/libreoffice/stable/7.6.6/win/x86_64/LibreOffice_7.6.6_Win_x86-64.msi.mirrorlist

Thank you

Actual behavior

please suppresses the false update message for the version 7

Environment

winget --info
Windows-Paket-Manager v1.7.10861

Windows: Windows.Desktop v10.0.19045.4170
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.22.10861.0

WinGet-Folders
- - -
Protokolle %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
Benutzereinstellungen %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Verzeichnis für portierbare Links (Benutzer) %LOCALAPPDATA%\Microsoft\WinGet\Links
Portables Linkverzeichnis (Computer) C:\Program Files\WinGet\Links
Portierbarer Paketstamm (Benutzer) %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portierbarer Paketstamm C:\Program Files\WinGet\Packages
Portierbares Paketstamm (x86) C:\Program Files (x86)\WinGet\Packages
Installationsprogrammdownloads %USERPROFILE%\Downloads

Administrator-Settings                  Status
- - -
LocalManifestFiles                        Deaktiviert
BypassCertificatePinningForMicrosoftStore Deaktiviert
InstallerHashOverride                     Deaktiviert
LocalArchiveMalwareScanOverride           Deaktiviert

[stephengillie]

I believe version 7 manifests have been moved into TheDocumentFoundation.LibreOffice.LTS. Are you still seeing the issue?

or is it caused by the strange ID? TheDocumentFoundation.LibreOffi

This might be from a separate bug.

Edit: I was mistaken - We have to re-validate every manifest during the move, but this is delayed due to their host's rate limiting, and so we can only move a small number of manifests per day.

[useforgh]

@stephengillie

• no uniform consistency

• outdated cache leads to further problems

no uniform consistency Oh... I noticed that the strange ID "TheDocumentFoundation.LibreOffi" was only displayed when I entered a winget command combined with a "| find "Libre" - so this wasn't the cause.

LibreOffice v. 7 is not related in any case with the LTS. winget list: relation to LTS is updated but winget list --upgrade-available -> it's still related with the v.24 why?

But the reason why this can happen and how to prevent this in the future...

I've seen various mismatches in the last six months. Some of these were prominent software like Firefox, Edge and Google browser. Also the Microsoft Visual C++ 2015-2022 Redistributable (x64) was related with the wrong ID "Microsoft.VCRedist.2008.x86" for many weeks. And it's true that various pre-release versions are continuously offered as regular updates.

However, I am not sure whether there is an option to block pre-releases at all.

In my opinion a blind mass update via update all at once is a high risk. Every update via winget needs a deep review.

• outdated cache leads to further problems

An unknown cache error avoids to use newest data

I figured out an inconsistent winget status between my productive machines which have almost the same software with the same version installed. Nevertheless winget shows from time to time different updates or no update but other machines get offers for newer updates and it remains for weeks.

It looks like that there is a - I name it cache. But winget hasn't implemented any check to proof whether it is up to date. Just an uninstallation of winget souce will fix it partial.

as admin: winget uninstall Microsoft.Winget.Source_8wekyb3d8bbwe winget source reset --force

After this winget list shows on affected machines with formerly outdated software update offers the newest update versions like on my other machines. Ok, this will not fix ongoing mismatches but it fix the "outdated cache". In the case if you use winget list --upgrade-availablet it still offers the wrong version. I am not familiar with deeper details of winget. But for me is this problem caused through an outdated and never checked cache function in the winget environment. And it looks like, that there are several caches which leads to differnt results with "winget list" and "winget list --upgrade-available". As we see: to reinstall the winget source is not the way to fix everthing.

I've no idea why winget doesn't check on a machine why or if this cache is up to date or not. If winget would check it, then it could fix it with a background task and if it fails, then winget could prompt an info for the user and or could write an entry in the system evt log. But this check is still missing and causes many effords.

A user with only one PC can never be aware of it whether his winget shows or use the newest data in every case and this means we need a winget background task to check this nebulous circumstance with the cache.

Thank you

[useforgh]

@stephengillie

... 10 hours later

winget list AND winget list --upgrade-available

both offers the wrong v.24 again

We can never unchecked believe anything in winget.

Without having checked it on the winget db servers, such statements like to believe anyone has related the correct upddate are demonstrably worthless.

Any allegedly partially correct results at the moment can return to their original incorrect state after a few hours.

winget is still just loosing game and therefore is only one possibility: no matter what result winget shows you. never trust winget

[stephengillie]

Please understand that we're working with a system with a huge variety of inputs. We're not actively trying to sneak pre-release versions into mainline PackageIdentifiers, but instead doing our best to mitigate and handles these situations once they're identified.

This is why we've worked to move v24 into a separate PackageIdentifier. Your posts are something of a bug report, and would be much more helpful if they had more technical data. Copy-pasting WinGet output is recommended.

Feel free to join our efforts to mitigate these issues, and also feel free to use the package manager of your choice.