[wix-devs] 6297 fallout

[Bob Arnson]

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/