[wix-devs] 6297 fallout

[Ron Martin]

Although I'm not up on the topic of bundles and their dependencies, I'm
pretty good on logic and processes, so let me give this topic a generalist's
view: (If you'd rather I kept my thoughts to myself, just say the word.)

When a bundle has a dependency, the dependency should be reference
counted and installed (and installed if reference count is now 1) before the
dependent. If the bundle (or the dependent) fails to install, the reference
counter should be decremented (and uninstalled if reference count is now 0)
during rollback. If the real intent is that the dependency should be 
installed
regardless of the success or failure of the bundle installation, then the
dependency should be installed by some external means. This could be in
the form of a separate bundle that could be installed before the bundle 
under
consideration, assuming that you have some means of enforcing the order.
This provides a means of uninstalling the otherwise stranded dependency.

On 3/8/2021 5:16 PM, Sean Hall via wix-devs wrote:
> 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/