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 On Sunday, July 17, 2016 at 11:12:52 PM UTC+1, Bob Tanner wrote: > > 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. > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/17644bfe-3ff3-4f18-aebf-cec237bf4e20%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
