Why is package management so convoluted with Ansible and Windows?

[Bob Tanner]

Can someone send me some links about why it's so convoluted to get Ansible manage of software packages on Windows?

Even with all the flavors of package managers on the Linux side of things Ansible does a great job. 

Moving into the Ansible manage of Windows world things just seem so convoluted.

I don't do much Admin in Windows so I might just be clueless.  But I've spent hours trying to figure out how to uninstall package (Quicktime in this instance).

Is that just the nature of Windows? Windows software packing? Lack of my knowledge?

Some answers I would like to get.

win_msi vs win_package

Is this like .deb vs .rpm? 

If I  have a .msi I know that's win_msi, but what if I got a .exe? Is that a win_package install? What if that .exe is self-extracting zip, do I use win_msi? win_package? Write tasks to run it (to unzip) and then see if I need to use win_msi or win_package?

I do not even know what to search for. I'm struggling with the questions to ask. And Google results for "Windows Sucks" aren't helpful.

Any info I can read about this would be helpful.

Thanks.

[Mike Fennemore]

With regards to package management the win_msi module seems to have been built purely for msi files whereas win_package is built with the option of other install files (exe etc).

Also the win_msi module is a core module whereas the win_package is an extras module developed by the community. As an additional you mentioned package managers for Linux. The rough equivalent for Windows is Chocolatey, which has its own win_chocolatey module which is version useful for deployment.

[J Hawkesworth]

I have a few ideas about why package management is a pain on windows.

The first is that there is an assumption baked into a lot of aspects of windows that there is someone sitting in front of the screen.  If you like windows is a 'workstation operating system'.  The computer is right there in front of the user - its the original embodiment of 'personal computing'.  

So many installers expect someone to be sitting there hitting Next or answering questions.  

A fair bit of windows software of course needs licensing too, which is another case where asking the user to provide some information at installation time is (not unreasonably) expected.

Another aspect of it is the registry which doesn't really have a linux equivalent.  Its a sort of (hierarchical)  database without transaction support (again another manifestation of the there's-one-user-who-is-sitting-in-front-of-the-machine thinking: why would you need transactions when the user can only really do 1 thing at a time).  The registry means you need to use apis to get things fully installed, whereas in the linux world a lot of the time you are just putting files in place (and running things).  Doing without the registry I think makes managing packages simpler and more reliable.

Uninstallers seem to get less testing than installers so I've found removing stuff from windows can be particularly tricky and on occasion I've given up trying to use the interfaces around the windows installer service (win_msi, win_package and using raw to call msiexec.exe) and removed the files using win_file and cleaned up the registry using win_regedit.  (java jdk 7 believe it or not).

Regarding win_msi and win_package, generally I'd recommend trying win_package first as for the most part it is more capable (handling .exe installers as well as .msi ones, and using the product id for idempotency checking, and can collect remote files from a url to install).  

In the end, you just have to try things (in a vm you can revert back to a snapshot preferably) in windows as installers are just a lot less standardized.

I have some stuff which came in self extracting .exes which I just unzipped and used 'raw' to run the installer for (having found the necessary command line switches to make it run unattended / silently).  Its not always pretty, but personally I'd much rather have a functioning playbook that lets me reproduce the same installation on whatever machines than waste more time endlessly running windows installers manually.

Windows is just fundamentally a different thing I guess.  Hope this helps a bit,

Jon