So I've been thinking about this change. Engine changes are so challenging
since you have to think about all the different ways things could end up
there. You've already done a great job of this so I'm wracking my brain to
think of other things. <smile/>
1. It's a bit unclear from your comments but did this change actually fix
the issue you were seeing? It seems like it should but I don't have a repro
scenario in front of me so... <smile/>
2. A test case for this would be ideal. Are you interested in adding one of
those? If so, I can point you in the right direction to do that using the
new xUnit test infrastructure.
Finally, Jakob, I don't think we have an assignment agreement for you. Can
we get that paper work out of the way:
http://wixtoolset.org/about/assignment-agreement/
On Thu, Jun 27, 2013 at 8:10 AM, Jakob Ziegler <subscr...@gmail.com> wrote:
> Hi
>
> I'd like to fix this bug: https://sourceforge.net/p/wix/bugs/3321/
> It got started in this question:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/a-patch-bundle-uninstall-doesn-t-remove-superseded-msp-patches-td7586582.html
> and
> I was told I could work on that myself.
>
> The intention would be that a bundle removes the patches it has installed,
> even though the patches are already superseded. Currently, the bundle
> leaves them on the system and uninstalls itself, leaving zombies. That's
> the case with FixPacks and superseding turned on, or all ServicePacks as I
> got the impression.
>
> But i've never done that before on a community project, so i'm a bit
> unsure about the proceedings.
>
> Also, since I've never done anything for WiX i wondered if someone could
> throw me a bone and tell me if starting in burns mspengine.cpp makes sense?
> I had a look at the code and ended in the
> mspengine::MspEnginePlanCalculatePackage method.
>
> There it looks like BOOTSTRAPPER_PACKAGE_STATE_SUPERSEDED just isn't
> mentioned and adding that (and treating it like ..._PRESENT) would kind of
> be a possible first step in the solution.
>
> I also see the problem that this would change the behavior of the engine
> and some might not like that, so I don't know if there'd be a requirement
> to configure that in the xml to retain backwards compatibility?
>
> Or if that's totally the wrong direction to go...
>
> Cheers
> Jakob
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs