[wix-devs] Reinstalling Bundle packages

[Sean Hall]

It didn't make the meeting notes (
https://www.firegiant.com/blog/2022/1/13/wix-online-meeting-227-highlights/),
but we discussed this at the end of the meeting and decided to go with
FORCE_PRESENT. That will always set the action to INSTALL for all package
types. FORCE_ABSENT will be changed to work the same way - the action will
always be set to UNINSTALL.

This wasn't discussed in the meeting but note that once #6459 is
implemented, Burn will be able to tell the difference between Permanent
ExePackages that can be uninstalled and those that can't. For
truly uninstallable packages, FORCE_ABSENT will cause the action to be NONE
instead of UNINSTALL.

On Tue, Jan 4, 2022 at 4:34 PM Sean Hall <r.sean.hall at gmail.com> wrote:

> It wouldn't be the same, unless we
> change BOOTSTRAPPER_REQUEST_STATE_FORCE_ABSENT to force the action to
> be BOOTSTRAPPER_ACTION_STATE_UNINSTALL even if it wasn't detected as
> present. The force part currently means "override Package/@Permanent".
>
> On Tue, Jan 4, 2022 at 4:25 PM Bob Arnson <bob at firegiant.com> wrote:
>
>> BOOTSTRAPPER_REQUEST_STATE_FORCE_PRESENT, a la
>> BOOTSTRAPPER_REQUEST_STATE_FORCE_ABSENT?
>>
>> -----Original Message-----
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
>> Hall via wix-devs
>> Sent: Tuesday, 4 January, 2022 16:01
>> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
>> Cc: Sean Hall <r.sean.hall at gmail.com>
>> Subject: [wix-devs] Reinstalling Bundle packages
>>
>> If you look at my PR for related bundles as BundlePackages in Burn, at
>>
>> https://github.com/wixtoolset/wix4/blob/eacdad8217c1cd17bd6eeadd736499e59e51e0ee/src/burn/engine/bundlepackageengine.cpp#L51
>> there's a special fPseudoBundle flag to allow installing even if the
>> bundle is already detected as present (this was in exeengine.cpp in v3). I
>> want to get rid of the fPseudoBundle flag so that related bundles will work
>> the same as BundlePackages when that's added to the language.
>>
>> Also, for 3421 I'm trying to figure out how to let the BA control the
>> behavior for upgrade bundles when it is rolling back. For example, maybe
>> the BA wants to opt out of rerunning the upgrade bundles or it wants to do
>> a repair instead of install. Again, we need to expose the ability for a BA
>> to request to install the bundle even though it's already present.
>>
>> I'm considering adding BOOTSTRAPPER_REQUEST_STATE_REINSTALL, but I don't
>> like that for the same reasons I didn't like
>> BOOTSTRAPPER_REQUEST_STATE_MEND:
>> * There won't be an overall action BOOTSTRAPPER_ACTION_REINSTALL
>> * BOOTSTRAPPER_REQUEST_STATE_REINSTALL can't be requested for MSI/MSP/MSU
>> packages
>>
>> For 3421, I would add a new requested state for the restore operation. I
>> guess another option would be a simple boolean flag like fDisableRestore,
>> and the BA wouldn't get to ask for repair.
>>
>> Does anyone have any other ideas?
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>