[wix-devs] 6297 fallout

[Bob Arnson]

OnDetectRelatedBundle: It's definitely plan-adjacent given that Plan takes an action. DetectForwardCompatibleBundle also looks at action.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, 9 March, 2021 21:31
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] 6297 fallout

OnDetectRelatedBundle: It's not technically planning since that information isn't stored in the plan. What's not just OnDetectRelatedBundle?

Patch planning: Yes, because of parallel caching.

On Tue, Mar 9, 2021 at 8:03 PM Bob Arnson <bob at firegiant.com> wrote:

> 5249: I would argue that leaving behind a cached package after the 
> bundle's gone is never a good thing(tm) -- unless it has its own ARP entry.
>
> OnDetectRelatedBundle: Urgh. Why does anything plan-related happen 
> during detect? And of course, it's not just OnDetectRelatedBundle...
>
> Failsafe: Yeah, good opt-in ideas. If not in the system, someone 
> always comes along taking a sledgehammer to the registry...
>
> MSI/MSP logging: Agreed, the actual command line should be logged.
>
> Patch planning: Because of parallel caching?
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> Sean Hall via wix-devs
> Sent: Monday, 8 March, 2021 17:16
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: [wix-devs] 6297 fallout
>
> While implementing the new registration logic in 6297, I came across 
> some problems that don't have clear answers. I'm not going to worry 
> about them if no one else cares, but if we come up with answers I'll 
> probably implement them.
>
> #3516 - I don't agree with the conclusion that the dependency should 
> be registered for a non-vital package that failed to install. The 
> bundle wouldn't have registered that dependency if it hadn't tried to install it.
> If the bundle truly depended on that package then it would be Vital.
>
> If that dependency is supposed to be registered, then there is a bug 
> today where rollback could uninstall that package even though it has dependents.
>
> This also has implications for #6309. The plan will have actions to 
> register the dependency for packages that were skipped. It's not clear 
> whether it should register dependencies for the skipped packages.
>
> #4033 - Rob closed this as fixed in v3.9, but I don't know how it 
> could be fixed if Burn never acts on Superseded or Obsolete patches. 
> After 6297 this means the bundle will always stay installed, unless 
> something else uninstalls the patch.
>
> #5249 - This was closed as a duplicate, but I don't think it should 
> have been closed as a duplicate. The issue is that a permanent package 
> is not uninstalled during rollback, but Burn uncaches it during 
> rollback. The person didn't want Burn to uncache it. Triage said 
> "Burn's doing the right thing -- without a bundle around, nothing would ever clean up the cache."
> This is not a valid argument. When Burn uninstalls a bundle that 
> installed a permanent package, it will leave that package installed and cached.
>
> OnDetectRelatedBundle - One of the things that Burn is sending to the 
> BA is the operation that would be taken on that related bundle. The 
> problem is that operation is being calculated based on the action that 
> was specified on the command line, and there's no way for the BA to 
> get the operation for the action it wants to take if that's different.
>
> Failsafe - This new logic from 6297 is very likely to expose some 
> other bugs that end up making the engine never uninstall the bundle. 
> It might be a good idea to add a way to force uninstall the bundle, 
> and maybe even force the engine to never load the BA. Continuing with 
> that line of thought, it might be a good idea for a bundle to be able 
> to opt-in to never loading the BA when run silently and/or as a related bundle.
>
> MSI/MSP logging - Burn doesn't log the complete properties string sent 
> to MSI. It adds more parameters after logging, like REINSTALL, 
> REINSTALLMODE, and REBOOT.
>
> Patch planning - Burn currently optimizes for speed by trying to plan 
> all patches that target the same product together. This can cause it 
> to try to install a patch before it has been cached.
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/