[wix-devs] 6297 fallout

[Sean Hall]

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/
>