[kepler-dev] [Bug 5161] can't always use Module Manager to change to an older patch of a suite

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5161

--- Comment #1 from David Welker <david.v.welker at gmail.com> 2010-09-07 09:10:18 PDT ---
This is an interesting point.

The issue is this. If you a suite references ^ at the end, it means, use the
latest available patch. Your question is, what if the user wants a different
behavior AFTER they already have downloaded the newer patches. That is, maybe
they find that the new patches don't work for them (despite the fact that
patches should normally be nothing more ambitious than minor bug fixes).

The issue is definitional, actually. Module foo-2.1.^ means use the latest
patch available on your system. Module foo-2.1.3 means use exactly foo-2.1.3,
even if food-2.1.4 is available. If a precise patch was required, then the
suite developer can and should specify a precise patch.

However, the situation we have here is where the user wants to roll back the
application of the older patch. Perhaps things worked fine for them before the
patch and the "bug fix" in question was actually harmful to their work.
Clearly, a developer who specifies module foo-2.1.^ rather than a more precise
version would not have been in a position to anticipate this.

It should be noted that this problem is solvable outside of the module manager.
And that is probably how it should be solved. All the user who wants a precise
version has to do is either move or delete the latest patches from
<user.home>/KeplerData/kepler.modules/ or they can change modules.txt in
<user.home>/KeplerData/kepler.modules/build-area.

The reason I am hesitant to try to solve this problem within the module manager
is because:

(1) This should be a relatively rare problem, assuming that patching is used
appropriately, users should not normally demand to roll back patches. 

(2) We would actually have to change the definition of ^. Somehow, instead of
referring to the latest patch available on the system, ^ now would refer
sometimes to the latest patch available sometimes and actually an older patch
at other times. I am not even sure how this could be made to work. Although I
am probably clever enough to think of a way, it probably wouldn't be pretty. I
think we would lose enough in clarity concerning the meaning of ^ that allowing
the user to solve this problem through the module manager might be unwise.

(3) On the other hand, I could imagine implementing a "rollback" feature
accessible through the module manager. It would be possible for the module
manager to be aware of EXACTLY what state the module manager was in previously
and "rollback" or "undo" back to that state. This would not involve changing
the definition of ^, since what the module manager would remember is the exact
list of modules involved and not the previous suite.

However, I am not sure that implementing a rollback feature for 2.2 is a
priority. I am therefore tempted to close or postpone this bug, but will wait
for other opinions before doing so.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.