-
Notifications
You must be signed in to change notification settings - Fork 905
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with Minor MSI Upgrades #49
Comments
Is there already a way for me to force a chocolatey package to appear installed without installing it? I'm thinking about situations like the above where I already know the pre-requisite is installed, it's just not installed by chocolatey. Something like: |
--skippowershell. On Sunday, February 1, 2015, DarwinCSIWindowscom [email protected]
Rob http://devlicio.us/blogs/rob_reynolds |
Also --ignoredependencies On Sunday, February 1, 2015, Rob Reynolds [email protected] wrote:
Rob http://devlicio.us/blogs/rob_reynolds |
Could you please show a complete command line? I tried -skippowershell and --skippowershell and --skip-powershell and they all report "unknown option" and then "command install failed". I tried adding "-o" and "--override" and still get the same result. Latest version of chocolately on a fresh Server 2012 build. Thanks for any help! |
When you say latest version, can you confirm exactly what version? We have a beta package of Chocolatey, which is version |
You are correct - how do I update to the beta - doesn't seem to be a pre-release of the regular package, but not sure if I'm checking correctly. Also interested in the oneliner to install the beta on a bare machine if there is one. Thanks! |
If you already have choco installed use: choco install Chocolatey -pre For a fresh machine, there is a url you can use, but I am AFK. @ferventcoder, you around? Sent from my Windows Phone From: DarwinCSIWindowscommailto:[email protected] You are correct - how do I update to the beta - doesn't seem to be a pre-release of the regular package, but not sure if I'm checking correctly. Also interested in the oneliner to install the beta on a bare machine if there is one. Thanks! Reply to this email directly or view it on GitHub: |
@DarwinCSIWindowscom on a fresh machine, rather than doing this:
use this:
instead. That should get you the latest pre-release version. |
:) |
I am getting the error that there is no longer a "sources" command - do you want me to submit an issue somewhere? Also it is prompting for confirmation for each package - is there a way to globally disable that so that it behaves like the prior version? I can see in the command lines that there is a confirmation prompt, but would prefer not to update all my scripts with the confirmation prompt for every package. Thanks, |
@DarwinCSIWindowscom Please read the documentation. https://github.com/chocolatey/choco/wiki/ReleaseNotes |
I highly recommend you get familiar with |
For your global insecure confirmation option - #52 |
There doesn't look like they're is anything too do in this issue so I'm going to go ahead and close it. We can always reopen it again later, if necessary. |
This was experienced with the package sql2012.nativeclient
When installing on server 2012 I get the following error "Microsoft SQL 2012 Native Client: A network error occured while attempting to read from the file: c:\users\administrator\appdata\local\temp\chocolatey\SQL2012.NativeClient\sqlncli.msi"
When I visit that folder the MSI appears to be called "SQL2012.NativeClientInstall.msi"
Renaming the file appears to be a standard operation of the Chocolatey framework as they are all like this.
This package is being installed as a dependency for sql2012.powershell.
This machine already has the SQL native client via a previous install of the SQL engine and SQL management studio.
So at the MSI level, here is what is happening:
When MSI does an official MSI Minor upgrade to an existing product, it finds the same product code installed on the machine. From the previous run it can tell the original file name that is registered in the MSI repository.
If the previous version was installed as an "MSI managed package", it then goes back to the new location the current version is being installed from and looks for the previous original name in that location.
It would take a long time to explain - but this is a way of preventing non-admin users from gaining MSI admin rights by upgrading an existing MSI on the system that was installed by an admin.
To eliminate these types of conflicts, you would want to not engage in a practice of renaming the MSI files.
A second, and even better thing to do, would be to have the chocolatey framework intelligently detect whenever an MSI is already installed and check versions. From there your options would be to [a] do the correct MSI command line to accomplish a minor upgrade (always uses "msiexec /fvomus .msi") [many packages aren't written correctly to accomplish a minor upgrade, [b] or better uninstall the previous version [works for imperfect MSIs and for major upgrades], [c] or at the chocolatey level, just mark the package as installed if it is the SAME or older version (doing this when the new MSI is truly new is probably not be what people expect of an installation framework that is supposed to automatically do everything correctly)
The text was updated successfully, but these errors were encountered: