Implement the new mechanism we are going to use for handling Chromium updates

while it is in use. This should work for per user as well as system level
installs (after some additional changes once Google Update changes are ready).
The following scenarios should work now:
- If Chromium is using two different profiles at the same time we do not switch
chrome executables until all of them are closed.
- The old version of Chromium can be run after a restart if the renaming of
executables fails.
- We will not use environment variable any more but we need to keep it until all
the users get this change on their machines.
- opv/rename registry keys and new_chrome.exe should always together. If one
exist all three should exist because they are created and deleted as one atomic
operation (as much as possible given laws of physics).
BUG=1463346

Review URL: http://codereview.chromium.org/9436

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4949 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 5 insertions, 0 deletions

diff --git a/chrome/installer/util/work_item_list.h b/chrome/installer/util/work_item_list.h
index 5d1b071..227533c 100644
--- a/chrome/installer/util/work_item_list.h
+++ b/chrome/installer/util/work_item_list.h
@@ -44,6 +44,11 @@ class WorkItemList : public WorkItem {
   // path.
   bool AddCreateRegKeyWorkItem(HKEY predefined_root, std::wstring path);
 
+  // Add a DeleteRegValueWorkItem that deletes registry value of type REG_SZ
+  // or REG_DWORD.
+  bool AddDeleteRegValueWorkItem(HKEY predefined_root, std::wstring key_path,
+                                 std::wstring value_name, bool it_str_type);
+
   // Add a DeleteTreeWorkItem that recursively deletes a file system
   // hierarchy at the given root path. A key file can be optionally specified
   // by key_path.