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. RedHat/Novel cannot make a RPM for Oracle, as they cannot repackage/redistribute Oracle products.
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. 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). 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... Mauro http://mauro.limeiratem.com - registered Linux User: 294521 Scripture is both history, and a love letter from God. On Fri, Apr 23, 2010 at 2:17 PM, Clovis Pereira <[email protected]> wrote: > > Hello, > I see two points of views here: > > 1- A fake-rpm is easy and fast to implement, but not a definitive solution. > 2- A complete installation package, for a lot of platforms, but more > difficult to be wrote. > > Both are good ideas. The keyword to chose between them is: urgency. > > Regards, Clovis. > > > > I think the idea here is provide an "fake" rpm which depends on the > > same > > dependencies as Oracle DB do. So, installing this > > "oracledeps-fake-virtual-10.2.0.2.rpm" will install the dependencies, > > and > > you will be able to install Oracle without having to check manually > > gcc, > > libgcc, openmotif, libaio, etc... > > > > And this is a good idea. > > Oh, I'm not disagreeing that the fake RPM is a step in the right direction; > but it's not far enough. If you're going to package a product for a > platform, do it in a way that doesn't circumvent the software management > system. > > Sorry, I guess I'm just in a grumpy mood today. This kind of stuff (trying > to be "half-pregnant" by partially complying with RPM) makes migration and > upgrade a PITA in that the vendors *think* they have deployed a solution, > but they're still causing maintenance, deployment and support problems. > IMHO, we should be asking Oracle to play *by* the rules, not hack around > the rules. > > I also know they can't do everything at once, but we need to provide them > some guidance on what they should be focusing on so they can plan to > correct it later. > > ---------------------------------------------------------------------- > 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 > > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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
