win_pkg: does not check for SystemComponent in Uninstall registry keys

[morganwillcock]

Since this key isn't checked the reported version of applications can be incorrect where an MSI installation process actually handled installation, but the application is managed at a higher level by another product e.g. Adobe Air

As an example:
reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{4C00BFFA-9D98-7F05-96CE-4E472143C43A} /v Display*

    DisplayVersion    REG_SZ    255
    DisplayName    REG_SZ    Scratch 2 Offline Editor

reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\edu.media.mit.Scratch2Editor /v Display*

    DisplayVersion    REG_SZ    446
    DisplayName    REG_SZ    Scratch 2 Offline Editor

The first value should have been ignored in favour of the second, since the first is flagged as a system component:
reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{4C00BFFA-9D98-7F05-96CE-4E472143C43A} /v SystemComponent

    SystemComponent    REG_DWORD    0x1

Version 446 is listed in "Programs and Features" but win_pkg reports the wrong value:
salt salt-test pkg.version mit_scratch_2

salt-test:
    255

Tested on 2015.8.8.2

[damon-atkins]

Ran my code over this its reported as version 255.0.0
They are setting the binary version to 255.0.0 and the display version to 255

MIT need to fix it. They have made a bad package/install This indicates they have release 255 major releases.

    install_date:
        20160520
    packager:
        winmsi
    size:
        88311
    summary:
        Scratch 2 Offline Editor
    vendor:
        MIT Media Lab
    version:
        255.0.0
    win_advertise_flags:
        388
    win_display_name:
        Scratch 2 Offline Editor
    win_display_version:
        255
    win_install_location:
        C:\Program Files (x86)\Scratch 2
    win_instance_type:
        0
    win_language:
        en_US
    win_package_code:
        {8EC964DA-D411-7B20-A99B-9962713680F1}
    win_reployment_flags:
        3
    win_system_component:
        True
    win_uninstall_cmd:
        MsiExec.exe /I{8EC964DA-D411-7B20-A99B-9962713680F1}
    win_version_src:
        version

[morganwillcock]

I've already spoken to them and they say it's out of their control. Their application manifest doesn't define a version 255 and there is no MSI installer embedded in the Air file. These version numbers have come from actions taken by the Adobe Air application installer, and might even be a default value (255 as in hex ff).

I'm not sure what your code is meant to do or how it's doing it, but fundamentally this is a problem of two Uninstall keys with the same DisplayName, and package management ends up reporting a single package with the incorrect number. The solution shouldn't be specific to this problem or this package, it just demonstrates a need for some flexibility in how packages are detected.

Maybe this would be too specific:

# Default
prefer_system_component: None
# Would return 255
prefer_system_component: True
# Would return 446
prefer_system_component: False

Maybe something more like this:

ignore_when: <run something with cmd.retcode that returns 1 if it finds SystemComponent>
ignore_when: <run something with cmd.retcode that returns 1 for the next problem I need to solve>

[Ch3LL]

I think some more flexibility into how packages are detected is a reasonable request. I've notified @twangboy of this request and he has added it to this list of items for looking at possible additions to the win_repo. Thanks!

[damon-atkins]

The results are has/dict and the key is the key, you can only have one key, and it will be over written if something has the same generated key.
The only way to fix this is to use the registry key itself i.e. '{8EC964DA-D411-7B20-A99B-9962713680F1}' which is not user friendly. You would need to say pkg.install '{8EC964DA-D411-7B20-A99B-9962713680F1}'

This seems to have some info on it
https://books.google.com.au/books?id=753vtjjhSvsC&pg=PA399#v=onepage&q&f=false

As you can see the uninstall string is the same for both entries.

However SystemComponent (one with 255) are not listed in the "Uninstall or change a program" listing, I will add code for this to change the key/package name and so the name does not clash anymore in the new code I'm developing

Fixing this in the existing code set might cause existing users issues.

Windows Packaging is a mess (not salt), making hard to deal with every combination, its had about 8 years of exists.

reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\edu.media.mit.Scratch2Editor
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\edu.media.mit.Scratch2Editor
    DisplayIcon    REG_SZ    C:\Program Files (x86)\Scratch 2\Scratch 2.exe
    DisplayName    REG_SZ    Scratch 2 Offline Editor
    DisplayVersion    REG_SZ    446
    VersionMajor    REG_SZ    255
    VersionMinor    REG_SZ
    InstallLocation    REG_SZ    C:\Program Files (x86)\Scratch 2\
    Publisher    REG_SZ    MIT Media Lab
    UninstallString    REG_SZ    msiexec /qb /x {8EC964DA-D411-7B20-A99B-9962713680F1}

reg query HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{8EC964DA-D411-7B20-A99B-9962713680F1}
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{8EC964DA-D411-7B20-A99B-9962713680F1}
    DisplayName    REG_SZ    Scratch 2 Offline Editor
    InstallDate    REG_SZ    20160520
    InstallLocation    REG_SZ    C:\Program Files (x86)\Scratch 2
    InstallSource    REG_SZ    C:\Users\xxxxxxxxAppData\Local\Temp\AIRAF7C.tmp\Scratch 2\
    ModifyPath    REG_EXPAND_SZ    MsiExec.exe /I{8EC964DA-D411-7B20-A99B-9962713680F1}
    Publisher    REG_SZ    MIT Media Lab
    EstimatedSize    REG_DWORD    0x158f7
    SystemComponent    REG_DWORD    0x1
    UninstallString    REG_EXPAND_SZ    MsiExec.exe /I{8EC964DA-D411-7B20-A99B-9962713680F1}
    VersionMajor    REG_DWORD    0xff
    VersionMinor    REG_DWORD    0x0
    WindowsInstaller    REG_DWORD    0x1
    Version    REG_DWORD    0xff000000
    Language    REG_DWORD    0x409

[morganwillcock]

@Ch3LL thanks for looking at this, much appreciated.

@damon-atkins I think in most cases the default behaviour is sensible, it just needs some options that let you work around issues as you come across them. I've just found that anything built with WiX is potentially writing Uninstall data into the profile of the installing user. The new Python installers demonstrate the problem:
https://bugs.python.org/issue25166
wixtoolset/issues#4914
As you say, Windows packaging is a mess; I don't think directly accommodating the quirks of every packaging tool (or mistakes someone made when using it) directly into win_pkg is a realistic goal.

[damon-atkins]

Excel, Word, etc are components of Office. Unfortunately without components you can not tell who has install Word. Components are a an integral part of package management... For example from my reading System Component was original design for Drivers and the like.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.