[wix-devs] 6297 fallout

[Sean Hall]

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.