summaryrefslogtreecommitdiffstats
path: root/chrome/chrome_installer_util.gypi
Commit message (Collapse)AuthorAgeFilesLines
* Add support for the quick-enable-cf command to the installer. This encompases:grt@chromium.org2011-03-031-0/+4
| | | | | | | | | | | | | - Adding facilities for new-style Google Update commands (ProductCommand, ProductCommands) - Adding support to the validator to validate the quick-enable-cf command - Adding juju to the installation and uninstallation flows to put the command into place when installing/upgrading Chrome in multi-install mode when CF is either not installed or is in ready-mode, and making sure the command is not there when Chrome Frame is installed. BUG=none TEST=Install Chrome in multi-install mode and see if the Google Update version key for the binaries (app guid {4DC8B4CA-1BDA-483e-B5FA-D3C12E15B62D}) contains a key named "quick-enable-cf" that has a CommandLine value indicating setup.exe w/ --multi-install [ --system-level ] --quick-enable-cf, a SendsPings value of 1, and a WebAccessible value of 1. Then try the other variations, like install CF in ready-mode and make sure that quick-enable-cf is still there. Make sure that installing CF causes it to be removed, etc. Review URL: http://codereview.chromium.org/6588003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@76783 0039d316-1c4b-4281-b951-d872f2087c98
* Fix in-use updates where %TMP% is on a volume other than %USERPROFILE% ↵grt@chromium.org2011-02-241-0/+2
| | | | | | | | | | | and/or %SystemRoot%. We now do temp work on the same volume as the eventual install. In the case of system-level installs, this has the nice side-effect of allowing us to move the install into place rather than copy it, which should also speed up system-level installs. BUG=70368 TEST=Set TMP and TEMP env vars to some volume other than the one holding %USERPROFILE% (for user-level installs) or %SystemRoot% (for system-level installs), then see if in-use updates work. Review URL: http://codereview.chromium.org/6538091 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75899 0039d316-1c4b-4281-b951-d872f2087c98
* New installation validator machinery to check the machine state. This CL ↵grt@chromium.org2011-02-141-0/+2
| | | | | | | | | | | | | | | | contains the first two parts of the validator: 1. installer::InstallationValidator class, used by setup.exe to confirm that all is well following an installer operation. Violations are logged at ERROR level. 2. validate_installation.exe, used by humans to check the overall state of a machine. The third part, in which violations fire nonfatal test failures for use in other tests, will follow in a subsequent CL. BUG=none TEST=Run validate_installation.exe on machine(s) containing all conceivable permutations of Chrome and Chrome Frame, and see if it reports any violations. Review URL: http://codereview.chromium.org/6490024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@74819 0039d316-1c4b-4281-b951-d872f2087c98
* More installer refactoring in the interest of fixing some bugs and cleaning ↵grt@chromium.org2011-01-251-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | things up: - Introduced ProductOperations: an interface implemented for each product that takes care of product-specific functions. Each Product owns an instance and delegates certain operations to it. - Removed the use of MasterPreferences by BrowserDistribution so that the former isn't needed outside of the installer. - Replaced PackageProperties with a new BrowserDistribution type (CHROME_BINARIES) - Plumbed the concept of InstallerState more thoroughly through installer - Removed ProductPackageMapping and Package - Moved more registry read ops into ProductState - Validation of products to be installed is now done in CheckPreInstallConditions - Ignore --chrome-frame --ready-mode if chrome is also being installed/updated and a SxS GCF is found (chrome is updated). - Migrates existing single-install Chrome to multi-install where appropriate. - Fixes update to Chrome's uninstallation arguments when Chrome Frame is uninstalled. - Removed dead code from install.cc. - Added code to update products' "ap" values when ready-mode is accepted. - Skip post-install things such as launching the browser when Chrome was implicitly added to the install/upgrade process by virtue of being part of a multi-install. BUG=61609 TEST=run the installer, see it work. existing tests in installer_util_unittests have been updated; new tests are included for ProductState, ChannelInfo, etc. Review URL: http://codereview.chromium.org/6288009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72497 0039d316-1c4b-4281-b951-d872f2087c98
* - WriteInstallerResult is now back in InstallUtil and only writes the result ↵grt@chromium.org2011-01-051-2/+6
| | | | | | | | | | | | | | | | | | | | | where it is needed - WriteInstallerResult is no longer called on uninstall (Google Update doesn't check it on uninstall) - Introduced the poorly named InstallationState (state of the system based on registry inspection) and InstallerState (state of the current operation) classes - Product::GetInstalledVersion and Product::IsInstalled are gone; use InstallationState instead - A few cleanups to make the code comply with the style guide - UpdateDiffInstallStatus has been renamed to UpdateInstallStatus - Chromium builds noop in UpdateInstallStatus (this was always the case for the browser, but now also is for GCF and the multi-installer package). - The -multifail suffixes is now added to/removed from the Google Update "ap" value by UpdateInstallStatus on the basis of multi-install success/failure. - Added code to update the Google Update "ap" value based on the set up products/options installed - ChannelInfo is now an ordered list of modifiers and suffixes. We're careful to keep -full at the end since that was an operating assumption previously. - ActivePackageProperties is a typedef to either the Chrome or Chromium PackageProperties class TEST=Some existing unit tests updated; more new unit tests to follow. BUG=61609 Review URL: http://codereview.chromium.org/5988007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70483 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor the install flow in the Chrome installer to use a single ↵robertshield@chromium.org2011-01-041-0/+4
| | | | | | | | | | | | WorkItemList for all operations that mutate the system state. This is a prerequisite for meaningful unittests and significantly simplifies the install flow. BUG=61609 TEST=None (yet) Review URL: http://codereview.chromium.org/6078007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70426 0039d316-1c4b-4281-b951-d872f2087c98
* Support for GCF ready-mode.tommi@chromium.org2010-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The installer can now be run in a way that installs both Chrome and Chrome Frame at the same time, into a shared directory. The command line to do this is: mini_installer.exe --multi-install --chrome --chrome-frame --ready-mode --system-level --verbose-logging This installs both products although only Chrome will have an entry in the add/remove programs dialog that serves as an uninstallation command for both products. Chrome Frame will be installed in ready-mode, which means that the user will have to opt-in or opt-out of using it. The installer will create a REG_DWORD value to indicate this mode, here: HKEY_LOCAL_MACHINE\SOFTWARE\Google\Update\ClientState\{4DC8B4CA-1BDA-483e-B5FA-D3C12E15B62D} Value name: ChromeFrameReadyMode Value: 1 If the user opts-in to use GCF, setup will be run again to remove this value, update Chrome's uninstallation commands to only uninstall Chrome, and add an entry to the Add/Remove Programs dialog for GCF. To do this, the installer needs to be run with this switch: --multi-install --chrome-frame --system-level --ready-mode-opt-in --verbose-logging If the user opts-out, Chrome Frame will be uninstalled by running the installer with these arguments: --uninstall --chrome-frame --ready-mode --system-level --multi-install --verbose-logging In addition to uninstalling GCF, this updates Chrome's uninstallation commands accordingly and sets the ChromeFrameReadyMode value to 0 to avoid enabling ready mode again. Requirements that must currently be met in order to install Chrome and Chrome Frame into the same shared location: - Chrome Frame must not already be installed OR - Chrome Frame must be already installed as multi, into the shared location **** other changes **** The installer does no use the ap value for detecting other multi-install products anymore. Instead we inspect the uninstallation switches to see if --multi-install is present. Updated unit tests accordingly. When uninstalling Chrome Frame along with Chrome, the Chrome Frame uninstallation prompt is not shown. Added safeguards: If we attempt to install Chrome Frame multi over a single, install aborts and returns an error. If we attempt to install Chrome Frame single over a multi, install aborts and returns an error. TEST=See description above. BUG=61609 Review URL: http://codereview.chromium.org/5989007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70083 0039d316-1c4b-4281-b951-d872f2087c98
* - Installation results for use by Google Update are now written at the ↵grt@chromium.org2010-12-221-2/+2
| | | | | | | | | | | | | | | | | | Package level. Furthermore, such results are placed in the product keys as well as the package key, if there is one. This ensures that the result will be available for Google Update regardless of whether or not a migration from single to unified is taking place. - The mutex protecting creation of the window used to join chrome processes no longer contains the app_guid. This increases contention for the lock slightly, but ensures that window creation is safe in light of unified installs. - Fixed placement of the user data directory for Chrome Frame. Previously, GetChromeFrameUserDataDirectory contained its own, different, ChromeFrameDistribution::GetInstallSubDir implementation. Now, GetChromeFrameUserDataDirectory delegates to ChromeFrameDistribution. - Product now caches and owns the Version instance returned by is GetInstalledVersion method (msi state is also cached). Also added Product::IsInstalled. - Moved GetInstallReturnCode from BrowserDistribution to InstallUtil because I didn't see why it belonged to the dist class. - SetEULAConsent now writes the consent value to either the product or package key as appropriate. - Disallow --multi-install when operating on a SxS Chrome installation. - Propagate --multi-install when running setup.exe with --rename-chrome-exe so that installer results can get written to the correct place. BUG=61609 TEST=New tests added to installer_util_unittests for WriteInstallerResult and SetEULAConsent changes. Review URL: http://codereview.chromium.org/6061003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69944 0039d316-1c4b-4281-b951-d872f2087c98
* Installer cleanupamit@chromium.org2010-12-161-4/+0
| | | | | | | | | | | | | 1] Remove installer::version and use base::version in installer 2] Use file_util::FileEnumerator instead of calling FindFirstFile directly BUG=none TEST=covered by existing tests Review URL: http://codereview.chromium.org/5687004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69433 0039d316-1c4b-4281-b951-d872f2087c98
* Adding a new class, PackageProperties that represents the shared binaries ↵tommi@chromium.org2010-12-151-0/+2
| | | | | | | | | | | | | for each of the products. Also removing the system_level() property out of the Product class and into the Package class as system_level can't be different for products that share the same package. TEST=Run installer and unit tests. BUG=61609 Review URL: http://codereview.chromium.org/5744001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69314 0039d316-1c4b-4281-b951-d872f2087c98
* Some installer cleanup: introduced ChannelInfo class for fiddling with "ap" ↵grt@chromium.org2010-12-081-0/+2
| | | | | | | | | | | ClientState value. BUG=61609 TEST=added to and modified chrome/installer_util_unittests.exe appropriately Review URL: http://codereview.chromium.org/5656002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68603 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor the installer to support multi-install.tommi@chromium.org2010-12-011-0/+4
| | | | | | | | | | | | | | | | | | The installer now does its work based on distributions and target installation paths. Each distribution has exactly one target installation path but each installation path can have more than one distribution. In the absense of the --multi-install switch, the installer should continue to work as before. The biggest difference here is that we don't rely on a single global distribution object that controls the entire installation flow and we have a few classes for the new abstractions instead of global functions. It's far from perfect, but it's a step towards separating the core file package required for all distributions from the distributions themselves. Additionally, there are tons of little changes here such as consistant usage of FilePath and CommandLine instead of mixing them with std::wstring. TEST=Install, uninstall, upgrade, etc. Everything install related. BUG=61609 Review URL: http://codereview.chromium.org/5172011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67818 0039d316-1c4b-4281-b951-d872f2087c98
* The UI language rather than the locale is now used to pick Chrome's language ↵grt@chromium.org2010-11-161-0/+2
| | | | | | | | | | | | | | | on Windows. (Also fixed some unrelated lint errors.) With this change, l10n_util::GetApplicationLocale first checks for an override of the "configured locale" (in base::i18n) containing the list of preferred Windows UI languages. The browser triggers an override early in startup before the ApplicationLocale is determined. In effect, the browser no longer uses ICU on Windows for language detection. (This locale override mechanism is borrowed from the OS X port.) Changes in Chrome Frame are largely a refactor, as some Win32 code in there has been moved into base/win. Also cleaned up language selection in installer_util so that the proper language is chosen for the EULA, installer messages, and shortcuts. In so doing, replaced hand-crafted lists of supported languages with either auto-generated lists (static consts) or logic so that the addition of translations in the future doesn't require code motion (that being said, there may be reason to update the alias and/or wildcard tables in language_selector.cc). In so doing, this change unlocks Amharic, Farsi, and Swahili translations for installer messages and shortcuts. BUG=39986,40496,26470 TEST=New MUI/Win32 calls are tested in base/win/i18n_unittest.cc. To test the overall functionality, uninstall Chrome, remove intl.app_locale user pref, switch to a supported display language (via the "Keyboards and Languages" tab of Win7's "Regional and Language" control panel, and install with { "distribution": { "require_eula": true } } in master_preferences (via -installerdata arg to setup.exe). If all goes well, both EULA and outer frame are in the same language as Windows. Also, from gwilson: "Install system-level Chrome in audit mode on a new machine, then go through the out-of-box-experience, select a language, and the in -product EULA (triggered by "require_eula" : true) and Chrome's UI should be in the language that the user selected." Review URL: http://codereview.chromium.org/4139010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66275 0039d316-1c4b-4281-b951-d872f2087c98
* Move wmi_util out of base and into chrome/installer/util since that's the ↵brettw@chromium.org2010-10-101-2/+4
| | | | | | | | | | only place where it's used. TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/3696001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@62123 0039d316-1c4b-4281-b951-d872f2087c98
* Reworked Avi's patch for master prefs implemented on mac ↵mirandac@chromium.org2010-08-231-16/+1
| | | | | | | | | | | (http://codereview.chromium.org/2903014/show), so that it will work with new first run sequence on Windows and Mac. BUG=44901 TEST=in bug Review URL: http://codereview.chromium.org/3148001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57099 0039d316-1c4b-4281-b951-d872f2087c98
* Make UpgradeDetector work on the Mac.mark@chromium.org2010-07-151-0/+15
| | | | | | | | | | This is the backend work only. There's no UI yet. BUG=45147 TEST=manual Review URL: http://codereview.chromium.org/3032001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52524 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup some unncessary dependencies on libxml.mad@google.com2010-06-271-1/+0
| | | | | | | | | | | As working on change committed in rev50132, instead of yet adding another project to the dependency list of libxml, I decided to abstract the dependency in the metrics helper. BUG=0 TEST=None Review URL: http://codereview.chromium.org/2753010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50952 0039d316-1c4b-4281-b951-d872f2087c98
* Linux/GTK: implement update notification.estade@chromium.org2010-06-031-0/+2
| | | | | | | | | BUG=45148 TEST=compile chrome with PRODUCT_VERSION manually set to something higher than the current version (e.g. 7.0.0.0), and manually set the upgrade detector time to something short (like 10 seconds). Launch chrome and wait a short time for the update notification to appear. The update notification should pulse every few seconds, and should stop pulsing when the user opens the wrench menu. The about menu item should launch a dialog that allows the user to restart chrome, restoring the current session. Review URL: http://codereview.chromium.org/2365003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48795 0039d316-1c4b-4281-b951-d872f2087c98
* Break gyp cycles on Linux.tony@chromium.org2010-05-241-0/+160
The cycle is between installer.gyp and chrome.gyp. The fix is to switch installer.gyp into installer.gypi and include it into chrome.gyp BUG=35308 Review URL: http://codereview.chromium.org/2067018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48007 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-30 09:09:27 +0000