> The problem is convince Oracle to create a RPM file, and I bet Oracle > will > not consider the idea, as it would be required to support the RPM.
That's exactly my point -- Oracle *should* be distributing software for a platform in the format that is compatible with the native platform software management system. They won't do it if we don't ask them to do it. If they expect to deliver their software into cloud systems, or any kind of rapid provisioning tool (regardless of vendor or OS), they have to package the tool in a way that it can be installed via automated processes. The current setup isn't easily compatible with that approach. RPM is just part of the question (but becoming a larger and larger part as other Unix workload is converted to Linux). > RedHat/Novel cannot make a RPM for Oracle, as they cannot > repackage/redistribute Oracle products. Nor should they. It's the application developer's responsibility to package their products correctly and compatibly. > I could build a Oracle RPM (only for myself, don't want to have Oracle > coming after me for disrespecting it's EULA). Create a spec file with > the > dependencies, create a pre-install script which will alter sysctl.conf, > limits.conf, etc, and start Oracle setup wizard. For uninstall, remove > $ORACLE_HOME, $ORACLE_BASE, $ORACLE_EVERYTHING, remove Oracle users, > copy > back sysctl.conf, limits.conf, etc. We all do that. Why should *we* be doing the work instead of the vendor, who gets paid $$$ to do it? And more over, why should ALL of us have to repeat it for each organization? Or be without a consistent way of finding out remotely what patches ARE installed so you can ensure that every system IS patched in a verifiable way? Or have to invent a different way of managing patches for every single vendor you deal with? The Unix world has been sloppy about this for decades. It's time for it to stop. > It will be a lot of work, but for people installing/uninstalling Oracle > every other week (like me) it will be done only once (I hope). Once per release, at minimum. And per-patch, if you have to maintain a lot of images. > Uninstall Oracle is not something that would break RPM databases. Only > delete everything Oracle-related, and you are done. Except for the pre- > reqs > left behind... And taking the entry out of the RPM database so your configuration management tools don't think it's installed when it isn't. Another point for using the native software management system is that most of them (whether RPM, apt, SES/E or VMSINSTAL) knows what it did (what files it installed and what it changed). It should know how to remove that information in a controlled way, or at least the files it installed in the first place. Simplifying that process is why modifying text config files is being replaced by making/removing entries in directories for most system services (see inetd.conf vs /etc/xinet.d/*). The tools are there to do what needs doing -- we need to ask the vendors to do it right. I guess it comes down to whether you're strict about configuration management or not. If you are, things that are delivered outside the software management infrastructure are more expensive to deploy and use overall because *you* have to do the packaging work. If you're not, then you pay the price when you have to upgrade and you forget about some small but critical thing that needed to be installed. In no way am I saying that the fake RPM is not useful. I think the question is when we start asking for vendors to play by the rules. IBM used to do the random-install-script-dumping-things-all-over-the-place approach until enough people told them to stop, and it started to cause THEM problems with rapid deployment. It's time to ask Oracle to stop. We know they can't do it this second, but they need to hear that it's time to stop. There's a small enough list of vendors that we can get them to do it right before they get in the habit of NOT doing it right. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
