Ok, so I think there is confusion. We do not yet have an API for scripts...but even if we did, I'm thinking this API would be called from the
install and uninstall scripts, not supplant them. If you used this mechanism during install, eventually you'd not need an uninstall script at all...because the system could track and undo everything you did during installation...assuming a complete API.
The current issue:
In the past, we've had to have uninstall scripts to both remove rpm's and do other stuff, like delete a file or something that you created in an install script. Currently, we no longer need the rpm removal hardcoded in the scripts...and in fact this will cause the uninstall script to fail. Because rpm removal is now automated in the lib, using PackMan on the server
and image, and a manual cexec command on the compute nodes.
So, changing the meaning of the scripts? Sorta. You no longer must have an uninstall script...the same way you no longer must have a post_clients script. Its optional. This is the first step toward moving us closer to a NEST approach.
-- John
On Tue, 22 Feb 2005, Jeff Squyres wrote:
On Feb 22, 2005, at 3:01 PM, John Mugler wrote:
Well, in the future, you will not have to have a script to uninstall something. You can still have a script, if you want one. I'm currently running the script after the rpm's get removed. Not sure if this is the correct order or not.
I'm not following at all.
Are you talking about changing the meaning of the currently-defined scripts? I think that that would be a Bad Idea(tm).
However, I'd be surprised if that's what you mean -- I'm guessing that I'm misunderstanding your meaning here. Can you explain further?
I'm not opposed to having a perl API *in addition to* the existing scripts (where there must be clearly-defined rules about which would get called if both exist). But it is useful to be able to have a script in any language -- not necessarily Perl (Perl isn't everyone's favorite language, you know :-) ). So if there's a technical reason for this, great. But again, if it's just someone's preference, I would argue against it.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
