Bug #5398
closed
Re-install of Kepler-x.y doesn't overwrite modules.txt
Added by David Welker almost 13 years ago.
Updated over 11 years ago.
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.
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.
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.
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.
As discussed, new bug is create at bug 5695. close this one.
Original Bugzilla ID was 5398
Also available in: Atom
PDF