[Bug 45317] New: updating wine mono does not change version in uninstaller.exe
https://bugs.winehq.org/show_bug.cgi?id=45317 Bug ID: 45317 Summary: updating wine mono does not change version in uninstaller.exe Product: Wine Version: 3.10 Hardware: x86 URL: https://dl.winehq.org/wine/wine-mono/ OS: Linux Status: NEW Keywords: download, regression, source Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Blocks: 34989 Distribution: --- I'm trying to do a new Wine Mono release to address https://www.winehq.org/pipermail/wine-devel/2018-June/127993.html, and I'm finding that the version shown in uninstaller.exe never gets updated. However, the files from the new package are installed, and MsiInstallProduct claims success. Steps to reproduce: * 'wine64 uninstaller' and remove wine mono * 'wine64 msiexec /i wine-mono-4.7.1.msi' * 'wine64 msiexec /i wine-mono-4.7.2.msi' I don't know when this last worked. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- Out of curiosity, does this depend on architecture at all? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #2 from Vincent Povirk <madewokherd(a)gmail.com> --- I'm using 32-bit Wine for the bisect, so apparently not. I said wine64 because 32-bit uninstaller and msiexec don't work correctly with wine mono on 64-bit prefixes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- Hmm, alright. If this is reproducible with current builds of mono I'll be willing to take a look at it later, to spare the regression test. All uninstaller.exe does is query the registry directly, so something in msi must be writing the wrong version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #4 from Zebediah Figura <z.figura12(a)gmail.com> --- I can't make sense of this code. When is the feature state supposed to be set? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |808f3158bbcf229d6eb935a7afe | |7291e9152ce1a CC| |hans(a)meelstraat.net, | |piotr(a)codeweavers.com --- Comment #5 from Vincent Povirk <madewokherd(a)gmail.com> --- 808f3158bbcf229d6eb935a7afe7291e9152ce1a is the first bad commit commit 808f3158bbcf229d6eb935a7afe7291e9152ce1a Author: Piotr Caban <piotr(a)codeweavers.com> Date: Fri Oct 20 22:18:41 2017 +0200 msi: Improve installation with no argument of already installed product. Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com --- Comment #6 from Piotr Caban <piotr.caban(a)gmail.com> --- I don't know yet where the problem exactly is but I can see some issues related to the msi file content. wine-mono-4.7.1 and wine-mono-4.7.2 have different versions but the same ProductCode. According to the documentation it's wrong. When I tried to install test msi installer that replicates this I've got following message on Windows: "Another version of this product is already installed. Installation of this version cannot continue. [...]". It will need more testing but I guess that we should block wine-mono-4.7.2 installation if wine-mono-4.7.1 is installed. I've tried changing ProductCode in wine-mono-4.7.2. After that I ended with both wine-mono-4.7.1 and wine-mono-4.7.2 being listed by uninstaller.exe. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Piotr Caban from comment #6)
I don't know yet where the problem exactly is but I can see some issues related to the msi file content.
wine-mono-4.7.1 and wine-mono-4.7.2 have different versions but the same ProductCode. According to the documentation it's wrong. When I tried to install test msi installer that replicates this I've got following message on Windows: "Another version of this product is already installed. Installation of this version cannot continue. [...]". It will need more testing but I guess that we should block wine-mono-4.7.2 installation if wine-mono-4.7.1 is installed.
I believe it should be possible to keep the product code for minor upgrades. Vincent has been doing that in the past IIRC. MSDN does state that major upgrades should change ProductCode. msi_check_publish returns a different value since your patch. Maybe we should get rid of that check in RegisterProduct and PublishProduct. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #8 from Vincent Povirk <madewokherd(a)gmail.com> --- I have never changed the product code. My understanding was that changing it would make the new MSI a different package instead of an upgrade of the same one. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #9 from Piotr Caban <piotr.caban(a)gmail.com> --- I've done much more testing and I think that the correct way is to do a "major upgrade" on every mono update. I think so because of the way how update needs to be installed by the user: - major upgrade - it's enough to click on the msi file to install the update, depending on msi file content old version will be preserved or removed - minor upgrade - has identical user deployment methods as small update - small update - needs to be installed as patch or complete reinstall, if you decide to do the minor upgrade new mono versions will need to be installed in following way: msiexec /I wine-mono-4.7.2.msi REINSTALL=ALL REINSTALLMODE=vomus There are also many restrictions regarding what can be done in small and minor upgrade, I don't think you want to pay attention to that on every release. I'll send some tests to msi to show that current behaviour is incomplete but kind of correct. I'll also take a look on how mono msi files are created and attach some propositions for how it can be changed. Vincent, you said that you've never changed the ProductCode because it will "make the new MSI a different package". UpgradeCode is what links them together. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #10 from Vincent Povirk <madewokherd(a)gmail.com> --- OK, so it sounds like I need to add an Upgrade table and some upgrade-related actions, keep the UpgradeCode the same between releases, and change the ProductCode every release? I don't know how we can cleanly transition to this from existing releases that do not have an Upgrade table. Also, we will need a way for third-party tools like winetricks to remove Wine Mono regardless of what version is installed. My understanding is that uninstaller --remove uses the ProductCode which would no longer be constant. I guess that in C we would use MsiEnumRelatedProducts to search by upgrade code. Maybe the (now more complicated) logic for removing the old product on upgrade or when needed by winetricks can do in addons.c? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #11 from Piotr Caban <piotr.caban(a)gmail.com> --- It's not a problem for winetricks. It is already checking the UUID from mono running "uninstaller --list |grep Mono |cut -f1 -d\|". It should probably be changed to at least "grep "Wine Mono". There's no problem with transition to this new scheme as long as you don't want to downgrade mono. After changing the installer it should remove all the older versions on install. If you want to downgrade mono, you will need to uninstaller newer version first. I'm not sure what you mean by the "more complicated logic for removing old product". It should be done by msi in RemoveExistingProducts action. Do you think about adding some kind of hack to deal with older installers? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #12 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 61612 --> https://bugs.winehq.org/attachment.cgi?id=61612 mono msi database changes This is an example of changes that needs to be made to uninstall older version of mono package. With this changes it behaves quite bad when older version is installed (we end up with 2 version of package being listed in uninstaller). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #13 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 61613 --> https://bugs.winehq.org/attachment.cgi?id=61613 what needs to be changed on every release (example) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #14 from Piotr Caban <piotr.caban(a)gmail.com> --- Created attachment 61614 --> https://bugs.winehq.org/attachment.cgi?id=61614 mono msi database changes that also allow downgrade It still doesn't solve the problem of older installers but with this change you can also downgrade mono by doing simple "msiexec /i ...". -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #15 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Piotr Caban from comment #9)
I've done much more testing and I think that the correct way is to do a "major upgrade" on every mono update. I think so because of the way how update needs to be installed by the user: - major upgrade - it's enough to click on the msi file to install the update, depending on msi file content old version will be preserved or removed - minor upgrade - has identical user deployment methods as small update - small update - needs to be installed as patch or complete reinstall, if you decide to do the minor upgrade new mono versions will need to be installed in following way: msiexec /I wine-mono-4.7.2.msi REINSTALL=ALL REINSTALLMODE=vomus
Most users don't handle these updates directly. I don't think it's too much to ask users who want to test an update to type a few extra characters. We could add an exe wrapper if we really needed a single click installer.
There are also many restrictions regarding what can be done in small and minor upgrade, I don't think you want to pay attention to that on every release.
Don't know about 'many', but you can't modify the feature tree. This hasn't been an issue so far, wine-mono has had a single feature from the beginning. Note that you can still add features and components. A major upgrade defines a new product, which means that the old product will be removed first. So even if there's a small number of files that have changed (a typical update), all of them will be deleted and rewritten. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #16 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to Hans Leidekker from comment #15)
Don't know about 'many', but you can't modify the feature tree. This hasn't been an issue so far, wine-mono has had a single feature from the beginning. Note that you can still add features and components. I misunderstood what "modify the feature tree" means. I though that we can't add features.
I'm still not sure what is the best way to go. How about doing something like this: - return error in msi when someone tries to install a package with different ProductVersion and unchanged ProductCode - this way users trying to install wine-mono with "msiexec /i wine-mono-ver.msi" will see that it didn't succeed - change appwiz.cpl to install minor/small updates with "REINSTALL=ALL REINSTALLMODE=vomus" options - maybe we should also add some upgrade tables to improve possible future major upgrades -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #17 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Piotr Caban from comment #16)
(In reply to Hans Leidekker from comment #15)
Don't know about 'many', but you can't modify the feature tree. This hasn't been an issue so far, wine-mono has had a single feature from the beginning. Note that you can still add features and components. I misunderstood what "modify the feature tree" means. I though that we can't add features.
I'm still not sure what is the best way to go. How about doing something like this: - return error in msi when someone tries to install a package with different ProductVersion and unchanged ProductCode - this way users trying to install wine-mono with "msiexec /i wine-mono-ver.msi" will see that it didn't succeed - change appwiz.cpl to install minor/small updates with "REINSTALL=ALL REINSTALLMODE=vomus" options - maybe we should also add some upgrade tables to improve possible future major upgrades
I agree with all three points. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #18 from Vincent Povirk <madewokherd(a)gmail.com> --- Is there a reason not to use "REINSTALL=ALL REINSTALLMODE=vomus" with a new install? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #19 from Vincent Povirk <madewokherd(a)gmail.com> --- Apparently REINSALLMODE will prevent any new features from being installed, so we would have to check for an existing version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #20 from Vincent Povirk <madewokherd(a)gmail.com> --- I was looking for documentation of minor upgrades, and according to this stack overflow question the install will fail if any component is removed: https://stackoverflow.com/questions/543505/msiexec-reinstall-all-reinstallmo... I don't think I can promise that components won't be removed, so major upgrades may be better. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #21 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Vincent Povirk from comment #20)
I was looking for documentation of minor upgrades, and according to this stack overflow question the install will fail if any component is removed: https://stackoverflow.com/questions/543505/msiexec-reinstall-all- reinstallmode-vamus-not-reinstalling-anything
I don't think I can promise that components won't be removed, so major upgrades may be better.
The idea was to do small upgrades when possible and major upgrades when necessary. You could detect changes that require a major upgrade in a build script. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #22 from Vincent Povirk <madewokherd(a)gmail.com> --- Adding that infrastructure, along with the ability to detect at install time (in appwiz.cpl or maybe a custom action) whether a minor upgrade is possible, doesn't seem worth it. If major upgrades work, I might as well use them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #23 from Zebediah Figura <z.figura12(a)gmail.com> --- From https://docs.microsoft.com/en-us/windows/desktop/msi/changing-the-product-co...: "The product code must be changed if any of the following are true for the update: Coexisting installations of both original and updated products on the same system must be possible. The name of the .msi file has been changed. The component code of an existing component has changed. A component is removed from an existing feature. An existing feature has been made into a child of an existing feature. An existing child feature has been removed from its parent feature." Since the commit 2d8a74e2643c49fbc18568c34eccd0af4a75fdee six years ago which made component GUIDs stable, there has never yet been the need to remove a component. Components have only been added, which is perfectly legal. The feature tree has never even been touched (but it would be perfectly valid to do so). On the other hand, a major upgrade requires a full reinstallation of the product, which is essentially wasteful in terms of time and space. Looking at your build script, it seems that if any of the above six conditions were satisfied, it would already have required manual intervention, so I don't really see how using minor upgrades by default would really result in any extra effort. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #24 from Vincent Povirk <madewokherd(a)gmail.com> --- Just because the GUIDs are in the build tree, that doesn't mean they go in the msi. Only directories that still exist will go in the component table. Also, sometimes I forget to commit the GUIDs. I should probably make the build fail in that case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #25 from Austin English <austinenglish(a)gmail.com> --- (In reply to Piotr Caban from comment #11)
It's not a problem for winetricks. It is already checking the UUID from mono running "uninstaller --list |grep Mono |cut -f1 -d\|". It should probably be changed to at least "grep "Wine Mono".
https://github.com/Winetricks/winetricks/commit/bb025afb76ad45bca9c803aedd3f... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #26 from Piotr Caban <piotr.caban(a)gmail.com> --- The wine part of the bug is already fixed. Should it be marked as fixed or do you prefer to keep it open until some changes in mono are made? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 --- Comment #27 from Mathew Hodson <mathew.hodson(a)gmail.com> --- Patch was committed to wine git. https://source.winehq.org/git/wine.git/commitdiff/cb6e92d3287e9768b2e535c0b3... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |cb6e92d3287e9768b2e535c0b3f | |a159b19ec26cf Status|NEW |RESOLVED --- Comment #28 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Since Wine Mono was updated I'm going to close this one now. Feel free to reopen or change the sha-1 if I made a mistake. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x CC| |mstefani(a)winehq.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #29 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 3.15. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45317 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |--- --- Comment #30 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 3.0.x milestone from bugs included in 3.0.3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org