Tag Archives: Oracle

Oracle removes gnome packages from its database requirements

As a sysadmin I try to make sure my servers will have the minimal installation needed in order for them to work. In most cases this policy works fine, but some applications depend on too much unneeded software like GUI or sound packages.

Two years ago I wrote about “Why does Oracle’s applications needs xscreensaver in order to run ?“. It seems that finally things have changed.

In it’s latest version of the 10g r2 release notes (B15666-14), Oracle dropped the control-center and gnome-libs packages from the software requirements. This change is only relevant for RHEL5, as the list for RHEL4 (x86_64) haven’t changed except from dropping xscreensaver and adding some other packages.

Notice that for RHEL5, 3 packages were added in order to let the installer display it’s graphical interface:

  • libXp-1.0.0 (i386)
  • libXt-1.0.2 (i386)
  • libXtst-1.0.1 (i386)

I’m glad to see Oracle update it’s software requirements as a lot of people in the databases world are afraid to make changes which are against the official documentation, regardless of how wrong it might be.

Leave a comment

Filed under Proprietary software, Red Hat Enterprise Linux, System Administration

Oracle and ncompress

I’ve been approached by someone installing Oracle Enterprise Manager with a problem of the installation fails due to not finding the compress binary. It seems that some of the Oracle products relay on the ncompress package for compressing.

While compress might be the UNIX standard for compressing, I’m curious why didn’t they changed the product to use gzip. Or at least to check whether ncompress is available and than use it. But failing because of that seems to much to me.

This isn’t the first time I’ve challenged Oracle’s dependencies, which I think sometimes aren’t minimal as they should be or complaint with common distribution standards.

1 Comment

Filed under Proprietary software

Commercial companies and (the lack of) changelogs

As a Debian maintainer, I got a habit of reading the changelog of packages I install or want/need to upgrade. My problems begin with these packages come from some commercial compay, as most of them don’t log their changes.

Oracle’s OCFS2 RPMs have this “useful” changelog:

* Fri Jun 23 2006 Sunil Mushran
– Add largesmp

* Sun Jan 25 2004 Manish Singh
– Initial rpm spec file


* Fri Jan 28 2005 Manish Singh
– Add ocfs2console

* Sat Jan 22 2005 Manish Singh
– Initial rpm spec

That’s a start, but not very informative one. The packages were last updated on November 2007, the changelog doesn’t mention the various changes done on the packages.

Skype’s Etch deb file has this changeog entry:

skype ( extra; urgency=low

* Added Changelog for compliance with debian rules.

— Skype Technologies <info@skype.net> Wed, 10 Aug 2005 17:50:14 +0300

When I read that my reaction was “gee, thanks for the changlog”. I’m glad companies recognize the debian policy and comply to it, but let’s not forget the files is there to have some substance. Having a empty (or a place holder) changelog isn’t the real essence of the debian policy rule.

These are just two examples I encountered, but these are also the companies who actually wrote a changlog. I see a lot of packages which have an empty changelog.

I know companies work differently from community projects, what I fail to understand why don’t provide more information about their products. They all have “a support matrix”, tons of documentation and such, but when I want to know if I can install the new package easily – I don’t have this info, and usually the documentation doesn’t mention these technical changes.

So, my message for the commercial companies: you have a lot to learn from community projects, especially for those companies what want to be a part of the free software world. We (the community) usually have a high standards and we expect you to keep them.

I’m sure you’ll also benifit from these standards, if you’re not already enjoying it.


Filed under Proprietary software

Why does Oracle’s applications needs xscreensaver in order to run ?

Working with some of Oracle’s products, made me wonder about their installation requirements as appears in the documentation.

Let start with Oracle® Database 10g Release 2. The installation guide for linux x86 says under “Checking the Software Requirements” it needs the following RPMs for RHEL 4.0:

  • binutils
  • compat-db
  • compat-libstdc++-296
  • control-center
  • gcc
  • gcc-c++
  • glibc
  • glibc-common
  • gnome-libs
  • libstdc++
  • libstdc++-devel
  • make
  • pdksh
  • sysstat
  • xscreensaver
  • setarch

Most of them are valid requirements when needing to compile C/C++ code (as it may be done inside the database). But why do I need to install gnome’s libraries, gnome’s control-center and xscreensaver?

I fail to see how are these 3 are related to running a database. It is reasonable to require these packages for running a graphical installation, but that’s not a runtime requirement! I even tested that with checking the database opened files while it’s been running.

I really don’t want to have these packages installed on servers unless I must, as I believe server should contain the minimal software required on top of the distribution default installation.

Another funny (and weird) fact is that for SELS 9.0 there isn’t any requirement for gnome’s control-center. For RHEL 3.0 there aren’t any requirements for the 3 packages…

Mentioning optional requirements are probably the best why to solve this, unless there’s some real requirement that eludes me. John Smiley’s “Installing Oracle Database 10g Release 2 on Linux x86″ has this for openmotif21 which is mentioned as needed only for Oracle demos.

The same happens for Oracle® Enterprise Manager in installation guide for linux x86 10g Release 2 (10.2), but this time the package requirements for RHEL 3.0 and SELS 9.0 don’t mention any of the 3 packages, whilst they are required for RHEL 4.0. Very weird.

The status for Oracle Application Server 10g Release 3 is similar.

I would be happy if someone could shed some light on the issue.


Filed under Proprietary software, Red Hat Enterprise Linux