A BA can override that behavior but I agree the default in the Burn engine
doesn't seem quite right in this case. The patch should be removed. I think
Burn should have enough information to know that it should pull out the
superseded patch in this case. Can you open a bug? If you're interested in
working on the fix yourself, feel free to start a discussion on wix-devs
about it.
On Sat, Jun 15, 2013 at 5:49 AM, Jakobz <subscr...@gmail.com> wrote:
> Hi all
>
> I'm trying to set up a patching system using burn. We do cumulative
> patching and previously had the msp patches set up to supersede one
> another.
> After installing the main bundle, followed by the patch bundles in sequence
> v1.1 => v1.2, I can either keep v1.1 displayed in ARPs updates (new
> upgradecode for each patchBundle), or let it automatically be removed by
> burn (same upgradecode).
>
> When v1.2 is then installed and v1.1 is immediately or later removed, it
> does find the superseded patch v1.1, but it does not remove it in any case:
> It just says SamplePackPatch detected as superseded, execute: None.
>
> [08F0:0730][2013-06-13T23:20:27]i100: Detect begin, 1 packages
> [08F0:0730][2013-06-13T23:20:27]i102: Detected related bundle:
> {1ad24786-fd8b-4229-840a-725f80e6baa9}, type: Dependent, scope: PerMachine,
> version: 1.0.0.0, operation: None
> [08F0:0730][2013-06-13T23:20:27]i106: Calculating patch applicability for
> target product code: {48C49ACE-90CF-4161-9C6E-9162115A54DD}, context:
> Machine
> [08F0:0730][2013-06-13T23:20:27]i101: Detected package: SamplePackPatch,
> state: Superseded, cached: Complete
> [08F0:0730][2013-06-13T23:20:27]i105: Detected package: SamplePackPatch
> target: {48C49ACE-90CF-4161-9C6E-9162115A54DD}, state: Superseded
> [08F0:0730][2013-06-13T23:20:27]i199: Detect complete, result: 0x0
> [08F0:0730][2013-06-13T23:20:30]i200: Plan begin, 1 packages, action:
> Uninstall
> [08F0:0730][2013-06-13T23:20:30]i207: Planned related bundle:
> {1ad24786-fd8b-4229-840a-725f80e6baa9}, type: Dependent, default requested:
> None, ba requested: None, execute: None, rollback: None, dependency: None
> [08F0:0730][2013-06-13T23:20:30]i201: Planned package: SamplePackPatch,
> state: Superseded, default requested: Absent, ba requested: Absent,
> execute: None, rollback: None, cache: No, uncache: No, dependency:
> Unregister
> [08F0:0730][2013-06-13T23:20:30]i299: Plan complete, result: 0x0
>
>
> At that point it's still ok, because bundle v1.2 is installed along with
> patch v1.2. But as soon as bundle v1.2 is removed, the user only sees the
> main bundle, and no patch bundle installed.
> However, the msp patch v1.1 is still on the system, so some libraries are
> not present in the state one would expect.
> Also, without bundle v1.1, it is next to impossible for the user to remove
> this patch if the msi packages are installed with visible=false, as I do
> it.
>
> The only solution I found so far is to _not_ mark the patches as
> superseding. I know that superseding means "patch has fixes of all previous
> patches", which doesn't mean that a non-superseding patch could not also
> have all fixes of the previous patches, right?
> But I fear that I haven't understood superseding completely. Currently, it
> feels like it's only there to provide a means to hide previous patches in
> ARP while keeping them installed. I haven't found anything which indicates
> that the software install/uninstall behavior is different whether supersede
> is set to true or false, nor that the installed components are different.
>
> Who decides that these actions in the detect and plan phase? The burn
> engine itself, or the BA?
> And is not removing superseded patches a bug, or is that by design?
> Maybe it's possible to configure burn / the BA to have the desired behavior
> of removing the superseded patch?
> Or would I have to write my own BA?
>
> I very much appreciate what you are providing with WiX, so far it's a
> really cool tool :)
>
> Cheers and thanks in advance
> Jakob
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
