BOOTSTRAPPER_ACTION_CACHE

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

BOOTSTRAPPER_ACTION_CACHE

Heath Stewart-3
Sean and Rob, during triage you mentioned that you didn't think CACHE should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL (synonymous with Absent often times), which logically makes sense. If LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in between source and install - exactly what the cache is for.

So do you really think this needs to change? At the very least, it should be close to LAYOUT which is also before UNINSTALL.

- Heath from my Surface Pro 3


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: BOOTSTRAPPER_ACTION_CACHE

Heath Stewart-3
Reviewing other changes I may need to make apart from removing command line support, CoreRecreateCommandLine does pass /cache and seems it would need to for the original scenario. But since command line args not understood by Burn are passed through, is this okay? Only a parent BA could do this, but then again - nothing now sets BURN_COMMAND::action to BOOTSTRAPPER_ACTION_CACHE. Do we just leave it up to the BAs to know when to set package stats to CACHE?

- Heath from my Surface Pro 3

From: [hidden email]
Sent: ‎Tuesday‎, ‎March‎ ‎3‎, ‎2015 ‎9‎:‎51‎ ‎PM
To: [hidden email]

Sean and Rob, during triage you mentioned that you didn't think CACHE should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL (synonymous with Absent often times), which logically makes sense. If LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in between source and install - exactly what the cache is for.

So do you really think this needs to change? At the very least, it should be close to LAYOUT which is also before UNINSTALL.

- Heath from my Surface Pro 3


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: BOOTSTRAPPER_ACTION_CACHE

Rob Mensching-7
In reply to this post by Heath Stewart-3

I can totally see that line of thinking but LAYOUT is actually an outlier, just like HELP. Honestly, if I could do it again, I wouldn’t add LAYOUT to the command-line either and make it more like what I imagined CACHE to be.

 

So, ignore LAYOUT then the states a package can move through from “less to more present” on a machine are:

 

UNINSTALL

CACHE

INSTALL

MODIFY

REPAIR

UPDATE (i.e. move to a newer version)

 

CACHE was missing. I thought it was always there. Ooops.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Heath Stewart [mailto:[hidden email]]
Sent: Tuesday, March 3, 2015 9:45 PM
To: WiX toolset developer mailing list
Subject: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE

 

Sean and Rob, during triage you mentioned that you didn't think CACHE should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL (synonymous with Absent often times), which logically makes sense. If LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in between source and install - exactly what the cache is for.

 

So do you really think this needs to change? At the very least, it should be close to LAYOUT which is also before UNINSTALL.

 

- Heath from my Surface Pro 3

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: BOOTSTRAPPER_ACTION_CACHE

Rob Mensching-7
In reply to this post by Heath Stewart-3

Why? Won’t “additional command-line arguments” be appended so that whatever was called “CACHE” on the command line (/cache or /store or /whateverBAchooses) would get put back on there?  Or am I not remembering the code correctly?

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Heath Stewart [mailto:[hidden email]]
Sent: Tuesday, March 3, 2015 10:53 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE

 

Reviewing other changes I may need to make apart from removing command line support, CoreRecreateCommandLine does pass /cache and seems it would need to for the original scenario. But since command line args not understood by Burn are passed through, is this okay? Only a parent BA could do this, but then again - nothing now sets BURN_COMMAND::action to BOOTSTRAPPER_ACTION_CACHE. Do we just leave it up to the BAs to know when to set package stats to CACHE?

 

- Heath from my Surface Pro 3

 

From: [hidden email]
Sent: ‎Tuesday‎, ‎March‎ ‎3‎, ‎2015 ‎9‎:‎51‎ ‎PM
To: [hidden email]

 

Sean and Rob, during triage you mentioned that you didn't think CACHE should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL (synonymous with Absent often times), which logically makes sense. If LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in between source and install - exactly what the cache is for.

 

So do you really think this needs to change? At the very least, it should be close to LAYOUT which is also before UNINSTALL.

 

- Heath from my Surface Pro 3

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: BOOTSTRAPPER_ACTION_CACHE

SeanHall
I find these discussions really hard without any requirements or design docs (which was why I tried to start writing them down).

I think Rob covered why it needs to be between UNINSTALL and CACHE.  That also makes it match BOOTSTRAPPER_REQUEST_STATE (where CACHE is between ABSENT and PRESENT).

I don't understand the question about the command line.  It'll be just like if your BA had a /forceinstall switch (which maybe made it ignore install conditions or something).  Burn will not understand it and put it in the command line that it gives to the BA.

I cloned your wix4 branch and built a test bundle to see how it worked (it looked the same as wix3 and I wanted to be lazy and use the command line switch):

Detected package: NetFx451Web, state: Present, cached: None 
Detected package: UpdateReplace2MSI.msi, state: Absent, cached: None 
Detected package: stuff1, state: Absent, cached: None 
Planned package: NetFx451Web, state: Present, default requested: Present, ba requested: Present, execute: None, rollback: None, cache: No, uncache: No, dependency: None
Planned package: UpdateReplace2MSI.msi, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: None, cache: Yes, uncache: No, dependency: Register
Planned package: stuff1, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
--- Begin plan dump ---
Plan action: Cache
     per-machine: true
     keep registration by default: true
     estimated size: 32768
Plan cache size: 32768
   Cache action[0]: CHECKPOINT id: 1
   Cache action[1]: PACKAGE_START id: UpdateReplace2MSI.msi, plan index for skip: 4, payloads to cache: 1, bytes to cache: 32768, skip until retried: No
   Cache action[2]: EXTRACT_CONTAINER id: WixAttachedContainer, working path: E:\testprojects\MBA4\UpdateReplace2Bundle\bin\Debug\UpdateReplace2Bundle.exe, skip until retried: No, skip until acquired by action: 2147483648
   extract package id: UpdateReplace2MSI.msi, payload id: UpdateReplace2MSI.msi, working path: C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2MSI.msi
   Cache action[3]: CACHE_PAYLOAD package id: UpdateReplace2MSI.msi, payload id: UpdateReplace2MSI.msi, working path: C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2MSI.msi, operation: move, skip until retried: No, retry action: 2
   Cache action[4]: PACKAGE_STOP id: UpdateReplace2MSI.msi, skip until retried: No
   Cache action[5]: SIGNAL_SYNCPOINT event handle: 0x3f0, skip until retried: No
Plan execute package count: 0
  overall progress ticks: 1
   Execute action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes
   Execute action[1]: CHECKPOINT id: 2
   Execute action[2]: PACKAGE_PROVIDER package id: UpdateReplace2MSI.msi, action: 1
   Execute action[3]: CHECKPOINT id: 3
   Execute action[4]: PACKAGE_DEPENDENCY package id: UpdateReplace2MSI.msi, bundle provider key: {9a719fca-3c38-4d7d-9461-82c730fc03de}, action: 1
   Execute action[5]: CHECKPOINT id: 4
   Execute action[6]: CHECKPOINT id: 5
   Rollback action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes
   Rollback action[1]: PACKAGE_PROVIDER package id: UpdateReplace2MSI.msi, action: 2
   Rollback action[2]: CHECKPOINT id: 2
   Rollback action[3]: PACKAGE_DEPENDENCY package id: UpdateReplace2MSI.msi, bundle provider key: {9a719fca-3c38-4d7d-9461-82c730fc03de}, action: 2
   Rollback action[4]: CHECKPOINT id: 3
   Rollback action[5]: CHECKPOINT id: 4
   Rollback action[6]: CHECKPOINT id: 5
   Dependency action[0]: PLANNED_PROVIDER key: {9a719fca-3c38-4d7d-9461-82c730fc03de}, name: (null)
--- End plan dump ---
Plan complete, result: 0x0
Apply begin
Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, options: 0x7, disable resume: No
Caching bundle from: 'C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\.be\UpdateReplace2Bundle.exe' to: 'C:\ProgramData\Package Cache\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2Bundle.exe'
Registering bundle dependency provider: {9a719fca-3c38-4d7d-9461-82c730fc03de}, version: 1.1.0.0
Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, resume: Active, restart initiated: No, disable resume: No
Verified acquired payload: UpdateReplace2MSI.msi at path: C:\ProgramData\Package Cache\.unverified\UpdateReplace2MSI.msi, moving to: C:\ProgramData\Package Cache\{3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}v1.1.0.0\UpdateReplace2MSI.msi.
Registering package dependency provider: {3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}, version: (null), package: UpdateReplace2MSI.msi
Registering dependency: {9a719fca-3c38-4d7d-9461-82c730fc03de} on package provider: {3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}, package: UpdateReplace2MSI.msi
Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, resume: ARP, restart: None, disable resume: No
Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, resume: ARP, restart initiated: No, disable resume: No
Apply complete, result: 0x0, restart: None, ba requested restart:  No

This is a Bundle that I reuse over and over again for testing, so the authoring's pretty weird:

    <Chain DisableSystemRestore="yes">
      <PackageGroupRef Id="NetFx451Web"/>
      <MsiPackage bal:PrereqPackage="yes" SourceFile="$(var.UpdateReplace2MSI.TargetPath)" />
      <ExePackage Id="stuff1" SourceFile="C:\Users\First\Downloads\Wix37.exe" InstallCondition="0 = 1" DetectCondition="WixBundleInstalled AND WixBundleAction = 5" />
    </Chain>

I don't like that the Planned package message says it will install the MSI, but it doesn't actually install it.  I'm not sure it should be registering any dependencies during the Cache operation.  Before I ran this test I didn't think it mattered that the BOOTSTRAPPER_ACTION_CACHE action wasn't using the BOOTSTRAPPER_REQUEST_STATE_CACHE state, but now I think it has to in order for the execute action to be None.  Which means that your pull request won't actually work without my pull request. Sorry.

I notice that there are two differences in the refactor of plan.cpp between our pull requests.  One is that you disable the rollback actions during the CACHE operation, I don't think you can do that - the packages will be left on the machine without any way to delete them (except manually).  Or am I missing something?

The other one's a toss up.  I chose to look at the special case of BURN_CACHE_TYPE_ALWAYS in ProcessPackage, and you did it in PlanDependencyActions.  Naturally I'm biased towards mine...

On Wed, Mar 4, 2015 at 10:49 AM, Rob Mensching <[hidden email]> wrote:

Why? Won’t “additional command-line arguments” be appended so that whatever was called “CACHE” on the command line (/cache or /store or /whateverBAchooses) would get put back on there?  Or am I not remembering the code correctly?

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Heath Stewart [mailto:[hidden email]]
Sent: Tuesday, March 3, 2015 10:53 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE

 

Reviewing other changes I may need to make apart from removing command line support, CoreRecreateCommandLine does pass /cache and seems it would need to for the original scenario. But since command line args not understood by Burn are passed through, is this okay? Only a parent BA could do this, but then again - nothing now sets BURN_COMMAND::action to BOOTSTRAPPER_ACTION_CACHE. Do we just leave it up to the BAs to know when to set package stats to CACHE?

 

- Heath from my Surface Pro 3

 

From: [hidden email]
Sent: ‎Tuesday‎, ‎March‎ ‎3‎, ‎2015 ‎9‎:‎51‎ ‎PM
To: [hidden email]

 

Sean and Rob, during triage you mentioned that you didn't think CACHE should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL (synonymous with Absent often times), which logically makes sense. If LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in between source and install - exactly what the cache is for.

 

So do you really think this needs to change? At the very least, it should be close to LAYOUT which is also before UNINSTALL.

 

- Heath from my Surface Pro 3

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs



------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: BOOTSTRAPPER_ACTION_CACHE

Heath Stewart-3
In reply to this post by Heath Stewart-3
I forgot about the additional command line args. That should work then.

Sent from my Windows Phone

From: [hidden email]
Sent: ‎3/‎4/‎2015 8:52 AM
To: [hidden email]
Subject: Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE

Why? Won’t “additional command-line arguments” be appended so that whatever was called “CACHE” on the command line (/cache or /store or /whateverBAchooses) would get put back on there?  Or am I not remembering the code correctly?

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Heath Stewart [mailto:[hidden email]]
Sent: Tuesday, March 3, 2015 10:53 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE

 

Reviewing other changes I may need to make apart from removing command line support, CoreRecreateCommandLine does pass /cache and seems it would need to for the original scenario. But since command line args not understood by Burn are passed through, is this okay? Only a parent BA could do this, but then again - nothing now sets BURN_COMMAND::action to BOOTSTRAPPER_ACTION_CACHE. Do we just leave it up to the BAs to know when to set package stats to CACHE?

 

- Heath from my Surface Pro 3

 

From: [hidden email]
Sent: ‎Tuesday‎, ‎March‎ ‎3‎, ‎2015 ‎9‎:‎51‎ ‎PM
To: [hidden email]

 

Sean and Rob, during triage you mentioned that you didn't think CACHE should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL (synonymous with Absent often times), which logically makes sense. If LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in between source and install - exactly what the cache is for.

 

So do you really think this needs to change? At the very least, it should be close to LAYOUT which is also before UNINSTALL.

 

- Heath from my Surface Pro 3

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs