Hi Rob
I think the same way about engine changes.
So, I tried to break this approach and make it do something it should not,
but couldn't come up with a case :) I also still think the same way that a
patch should be removed by the bundle with which it was applied, unless of
course some other bundle is still clinging on to it.... that's something I
didn't test, actually...
1. I did try the patched engine on my local machine: bundle, patch bundle,
2nd patch bundle, remove first patch bundle => msp patch was also removed.
The detect/plan message of the burn engine also looked like what i'd expect.
2. I thought about adding a unit test, and also started, but after I got a
unit test message that I need to set some special environment variable (and
possibly end up with a halfway installed bundle on my system), i stopped.
But i'd be happy to provide a unit test, and would appreciate some
pointers. Maybe also a comment on whether it's preferable to do all that in
a vm than on a real system?
I'll write an additional email about getting that assignment.
Thanks
Jakob
On Wed, Jul 10, 2013 at 4:42 PM, Rob Mensching <[email protected]> wrote:
> 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 <[email protected]>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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
