Re: Oracle RPM Question - Please Help Me Answer This Question

On Fri, Nov 13, 2015 at 12:11 PM, Jeremy Schneider < jeremy.schneider_at_ardentperf.com> wrote:

> On Fri, Nov 13, 2015 at 10:09 AM, Michael Cunningham
> <napacunningham_at_gmail.com> wrote:
> > Our admins have explained to the executives that Oracle is their biggest
> > technical debt because there is no standard. They feel there should be an
> > RPM that is used for the install instead of the normal install process.
> >
> > Can you please help me provide a response of why Oracle does not have an
> RPM
> > and why it is, or is not, a good idea to create a custom RPM?
>
> Hey Michael -
>
> It is possible to package Oracle binaries in OS packages like RPMs -
> I've done it in the past for at least one major Oracle customer. Not
> unheard of and actually I personally like many aspects of this
> approach.
>
> However it's far more complex of an issue than just throwing the
> binaries into an RPM package. The biggest problem is that if you
> really want to use OS package management, then you need to commit to
> *always* use OS package management or you've caused more problems than
> you solved. That means (1) you need to come up with your own internal
> naming scheme and versioning scheme and database to track which RPM
> contains which combinations of one-off patches and (2) you can never
> run opatch directly on a server anymore. Otherwise, the output of "rpm
> -q" actually becomes misleading when you're trying to track what
> versions of software are installed where.
>
> Any time you need a new one-off patch, you should technically create a
> new build/rpm and then push that rpm to the server. This process
> should ideally be automated (one-click rpm builds). The next big
> challenge becomes size. Every single one of these RPMs will now be
> multiple GBs. Multi-GB rpms are frankly a little unwieldy and very
> uncommon.
>
> You'll always be using out-of-place patching in order to retain the
> integrity of the rpm database. This will significantly increase disk
> space usage across all of your servers. Frankly, shouldn't be an
> issue in most modern data centers - but worth noting. Downtime is
> decreased with out-of-place patching but total deployment time is
> increased since you need to build a multi-GB rpm and push it to a
> server rather than a simple in-place (or even online) opatch
> operation.
>
> Conclusion: you *can* repackage oracle binaries as RPMs. However there
> are a few important costs to factor in, and IMO these are likely some
> of the reasons Oracle doesn't use this approach by default.
>
> -Jeremy
>
> --
> http://about.me/jeremy_schneider
>

-- 
Michael Cunningham

--
http://www.freelists.org/webpage/oracle-l