Windows Installer features "self repair" for installed applications. In essence this means that it will keep checking whether the files on disk and settings in the registry match what the respective package originally installed. These checks are generally not performed for everything that the package installed, but for what is referred to as "key paths".
In situations where you see self repair running in cycles, it generally means that some process on the system or another MSI has changed settings on the system that the package that subsequently self-repairs also changed. Like the guy said, it's like a humidifier and a dehumidifier fighting it out in the same room - or a dog chasing its own tail. You don't get anywhere till the conflict is found and eliminated. The MSI file will keep going "this is my resource, I am changing it back" over and over.
What is needed is to identify the conflict that the MSI files or system processes are quarreling about: http://www.installsite.org/pages/en/msifaq/a/1037.htm .
There are also other design errors in MSI files that can trigger the same problem such as key paths set to hard coded, user-specific paths: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self repair results. Another example is key paths set to folders that are not writeable for the System account. Still another example is a key path set to a temporary file (which the system will delete eventually).
As you see, there are many scenarios but always the same problem: an MSI file is checking that the current installation is correct, and finds a discrepancy that it then tries to fix.