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@winehq.org Reporter: madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45317
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Out of curiosity, does this depend on architecture at all?
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #2 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #3 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- I can't make sense of this code. When is the feature state supposed to be set?
https://bugs.winehq.org/show_bug.cgi?id=45317
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |808f3158bbcf229d6eb935a7afe | |7291e9152ce1a CC| |hans@meelstraat.net, | |piotr@codeweavers.com
--- Comment #5 from Vincent Povirk madewokherd@gmail.com --- 808f3158bbcf229d6eb935a7afe7291e9152ce1a is the first bad commit commit 808f3158bbcf229d6eb935a7afe7291e9152ce1a Author: Piotr Caban piotr@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@codeweavers.com Signed-off-by: Hans Leidekker hans@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=45317
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com
--- Comment #6 from Piotr Caban piotr.caban@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #7 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #8 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #9 from Piotr Caban piotr.caban@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #10 from Vincent Povirk madewokherd@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?
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #11 from Piotr Caban piotr.caban@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?
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #12 from Piotr Caban piotr.caban@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).
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #13 from Piotr Caban piotr.caban@gmail.com --- Created attachment 61613 --> https://bugs.winehq.org/attachment.cgi?id=61613 what needs to be changed on every release (example)
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #14 from Piotr Caban piotr.caban@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 ...".
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #15 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #16 from Piotr Caban piotr.caban@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
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #17 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #18 from Vincent Povirk madewokherd@gmail.com --- Is there a reason not to use "REINSTALL=ALL REINSTALLMODE=vomus" with a new install?
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #19 from Vincent Povirk madewokherd@gmail.com --- Apparently REINSALLMODE will prevent any new features from being installed, so we would have to check for an existing version.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #20 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #21 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #22 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #23 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #24 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #25 from Austin English austinenglish@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...
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #26 from Piotr Caban piotr.caban@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?
https://bugs.winehq.org/show_bug.cgi?id=45317
--- Comment #27 from Mathew Hodson mathew.hodson@gmail.com --- Patch was committed to wine git.
https://source.winehq.org/git/wine.git/commitdiff/cb6e92d3287e9768b2e535c0b3...
https://bugs.winehq.org/show_bug.cgi?id=45317
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |cb6e92d3287e9768b2e535c0b3f | |a159b19ec26cf Status|NEW |RESOLVED
--- Comment #28 from Gijs Vermeulen gijsvrm@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.
https://bugs.winehq.org/show_bug.cgi?id=45317
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x CC| |mstefani@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=45317
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #29 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.15.
https://bugs.winehq.org/show_bug.cgi?id=45317
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |---
--- Comment #30 from Michael Stefaniuc mstefani@winehq.org --- Removing the 3.0.x milestone from bugs included in 3.0.3.
-
wine-bugs＠winehq.org