microsoft / winget-pkgs

The Microsoft community Windows Package Manager manifest repository
MIT License
8.62k stars 4.48k forks source link

DisplayLink driver not updated #148199

Closed nolme closed 6 months ago

nolme commented 6 months ago

Hello, on my Windows 11 PC x64 Fr, I ran the command : winget list --accept-source-agreements --upgrade-available

It give me the result :

Nom                                              ID                              Version       Disponible    Source
-------------------------------------------------------------------------------------------------------------------
Discord                                          Discord.Discord                 1.0.9018      1.0.9035      winget
Terminal Windows                                 Microsoft.WindowsTerminal       1.19.10573.0  1.19.10821.0  winget
Opera Stable 108.0.5067.40                       Opera.Opera                     108.0.5067.40 109.0.5097.38 winget
Zoom                                             Zoom.Zoom                       5.17.10.33775 5.17.11.34827 winget
qBittorrent                                      qBittorrent.qBittorrent         4.6.3         4.6.4         winget
Microsoft Windows Desktop Runtime - 7.0.17 (x64) Microsoft.WindowsAppRuntime.1.4 < 1.4.3       7.0.17        winget
DisplayLink Graphics                             DisplayLink.GraphicsDriver      11.1.2774.0   11.2.3337.0   winget
7 mises à niveau disponibles.

It looks like the first 6 updates are realtive to current user and the last (DisplayLink) to computer.

Running PowerScript (using Datto RMM or Kaspersky Network Agent from Security Center) give me the same result :

$ListLogFilePath = Join-Path $env:TEMP "Winget_list.log"
Start-Process "$ResolveWingetPath\winget.exe" -ArgumentList "list --accept-source-agreements --upgrade-available" -Wait -NoNewWindow -RedirectStandardOutput $ListLogFilePath

$LogFilePath = Join-Path $env:TEMP "Winget_upgrade.log"
if($ENV:Application -eq "All"){
    write-host "Update all applications."
    start-process "$ResolveWingetPath\winget.exe" -argumentlist "upgrade --recurse" -Wait -NoNewWindow -RedirectStandardOutput $LogFilePath
} else{
    write-host "Update applications : $ENV:Application"
    Start-Process "$ResolveWingetPath\winget.exe" -ArgumentList "upgrade $ENV:Application" -Wait -NoNewWindow -RedirectStandardOutput $LogFilePath
}

Name                 Id                         Version     Available   Source
------------------------------------------------------------------------------
DisplayLink Graphics DisplayLink.GraphicsDriver 11.1.2774.0 11.2.3337.0 winget
1 upgrades available.

Question 1 : Is this a known problem with Display Link ? Question 2 : Is there a way to update user applications ? (maybe only for currently logger users ?)

Thanks, Vincent

Trenly commented 6 months ago

When attempting to upgrade the package directly, I see this message:

PS C:\Windows\System32> winget upgrade DisplayLink.GraphicsDriver
A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.
generrosity commented 5 months ago

@Trenly Hello MVP! Version "11.3" was released a month ago too.

Is it possible that the version detection is skipping this previously problematic app, or just need to wait for next detection cycle?

image

Trenly commented 5 months ago

Version "11.3" was released a month ago too.

Is it possible that the version detection is skipping this previously problematic app, or just need to wait for next detection cycle?

@nolme - there is not a detection cycle for this application. New versions need to be manually submitted

nolme commented 5 months ago

@Trenly : Hello, as I'm not very experienced on GitHub and this project, can I suggest this change somewhere?

Trenly commented 5 months ago

@Trenly : Hello, as I'm not very experienced on GitHub and this project, can I suggest this change somewhere?

I've already submitted a PR to add the new version

generrosity commented 3 months ago

@nolme - there is not a detection cycle for this application. New versions need to be manually submitted

Sorry @Trenly I'm also a bit fresh on this project, can can't find references to 'detection cycle' and keep hitting dead links like readme's Repology etc.

Is there a detection cycle or is it only individual PRs? If so, what is needed to set it up?

thanks for the replies on this already

Trenly commented 3 months ago

@nolme - there is not a detection cycle for this application. New versions need to be manually submitted

Sorry @Trenly I'm also a bit fresh on this project, can can't find references to 'detection cycle' and keep hitting dead links like readme's Repology etc.

Is there a detection cycle or is it only individual PRs? If so, what is needed to set it up?

thanks for the replies on this already

The only "detection cycle" is when a publisher uses one static URL and just changes the file that URL downloads (also known as a vanity URL). The bot "wingetbot" scans the repository every day checking for URLs that have a mismatched SHA256 and will attempt to update that specific manifest. There is nothing needed for this to happen, thes scans are performed on all manifests. However, this type of update doesn’t apply for applications that have different URLs for each version.

Some users have built automation for specific applications, but they are not official and are supported by community members. Therefore, if you wanted to have a "detection cycle" for any specific application you would need to code something up yourself or ask someone who has existing automation to add it to theirs. The "detection cycle" simply refers to the fact that these community supplied automations run in periodic intervals.

The vast majority of applications are not automated, and even when they are automated every update requires individual PRs - just that the automations would be creating the PRs