[ale] Glibc machinations

[Dow Hurst]

I've mentioned this before on the list but have another angle to 
attack.  I have an molecular modelling application that requires a 
particular version of glibc as far as I can tell.  If it is installed 
under SuSE8.2, SuSE9.0, RHEL3.0 it runs fine.  However, SuSE9.1 is where 
the application fails to start due to a runtime error related to glibc.  
Now, this problem will probably go away if we can afford to upgrade the 
application to the latest version, but that is expensive.  I'd like to 
know how I can install the older glibc rpm from SuSE9.0 without breaking 
the SuSE9.1 install.  My reason for this is that one user had SuSE8.2 
installed and did an upgrade to SuSE9.1.  The upgrade process told her a 
particular rpm shouldn't be upgraded because this modelling app (not an 
rpm) depended on it.  She chose to not upgrade that rpm (she didn't 
capture that info for me) and the upgrade continued.  She was completely 
happy with 9.1 but had this modelling app running.  I need to figure 
what happened and see if I can duplicate it.  Any ideas how the upgrade 
process figured out what rpm couldn't be upgraded?  The modelling 
application has it's own installer that doesn't interact with rpm at all 
during installation of the app.  Somehow the upgrader in SuSE9.1 looked 
at all the binaries on the system and determined what was needed.  
Thanks for your advice,
Dow