Bug #5398
closedRe-install of Kepler-x.y doesn't overwrite modules.txt
0%
Description
Whenever Kepler-x.y is installed, modules.txt is overwritten to reflect the default for Kepler-x.y. But, if Kepler-x.y is uninstalled and reinstalled, this will not occur a second time.
Consider the following example. A user installed Kepler-2.2. Then modules.txt will be overwritten properly. Imagine two subsequent scenarios:
(1) The user uninstalls Kepler-2.2 and then re-installs Kepler-2.2. In that case, modules.txt will no longer be overwritten properly. Clicking on Kepler.app may not result in Kepler-2.2 opening and the user might need to use the Module Manager.app to solve their problem
(2) The user uninstalled Kepler-2.2 and then installs Kepler-2.3. No problem. Modules.txt will be overwritten properly and clicking on Kepler.app will open in Kepler-2.3 just as expected without having to resort to using the Module Manager.app.
Updated by jianwu jianwu over 12 years ago
After discussing with Derik, the information about the bug is clearer.
I can reproduce the first scenario for kepler-2.2. The reason is because Kepler-2.2 reinstall will not overwrite ~/KeplerData/kepler.modules/build-area/modules.txt. So if the modules.txt is changed by other kepler versions or suites, Kepler 2.2 won't start.
The phenomenon is different for Kepler 2.3. After uninstallation and re-installation, Kepler 2.3 can start correctly (even ~/KeplerData/kepler.modules/build-area/modules.txt might be set by other versions). But if a user install kepler-2.3.0, download and switch to reporting-2.3.0, uninstall and reinstall kepler-2.3, and it start into reporting-2.3. This means it didn't overwrite modules.txt
Before we do any changes, I think we can agree on what the correct behavior it should be. In my opinion, re-installation should replace both existing version and existing suite, no matter this re-installation is newer or older than other Kepler versions on the machine.
Updated by jianwu jianwu over 12 years ago
After discussion with Dan, we think it is correct to keep its suite configuration even a Kepler version is uninstalled and re-installed. Many software uninstallation and re-installation keep user settings.
It means the following behavior is correct: if a user install kepler-2.3.0, download and switch to reporting-2.3.0, uninstall and reinstall kepler-2.3, and it start into reporting-2.3.
~/KeplerData/kepler.modules/build-area/install-id.txt records the Kepler version number. Since kepler 2.3, if the install-id.txt in ~/KeplerData/ and the install-id.txt in installation path do not match (no matter which is newer), Kepler will first copy modules.txt and install-id.txt from installation path to ~/KeplerData/kepler.modules/build-area/ and overwrite the old texts in the directory. It means Kepler can always start correctly after Kepler 2.3.
So this bug is only in Kepler 2.2, not in later Kepler versions.
We can discuss it during the next 2.4 release call. My current opinion is that we need to do nothing about this bug for 2.4 release.
Updated by Ilkay Altintas over 12 years ago
This was a 2.2 bug. It has been solved for 2.3. The behavior right now seems to be ok for 2.4, but the user needs to go through the process manually. This creates a usability problem for the user.
Add a new bug on the usability perspective of module upgrade management. Some of the process can be automated.
Updated by jianwu jianwu about 12 years ago
As discussed, new bug is create at bug 5695. close this one.