[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openpkg-dev
Subject:    RE: New oracle-barebone submission
From:       "Dennis McRitchie" <dmcr () Princeton ! EDU>
Date:       2004-01-30 16:44:08
Message-ID: 150d01c3e750$48228e50$6ceb7080 () princeton ! edu
[Download RAW message or body]

Ralf,

Depends on how you define "universal"  :-). My solution is universal in that
it allows all packages that use oracle-barebone to work flawlessly without
change (albeit for one %{l_prefix}). Yours only allows DBD::Oracle to work
with oracle-barebone.

Nonetheless, I agree that this is a drawback to my method. The problem is
that the oracle-barebone [no]src rpm package - unlike most of your src
packages - does not actually *build* anything: it just install files. All
the building is done when Oracle 9i is originally installed. In theory, if
there were a way to package the Oracle Universal Installer as part of the
oracle-barebone package, you could build and install it wherever you wanted.

Also, since this is a nosrc package, the package - as provided by OpenPKG -
can indeed be installed wherever you want. You merely have to use an
appropriate oracle bz2 file for the "build" of the nosrc package that you
are doing at the moment. And since we distribute only binary rpm's here,
they can only be installed in the designated %{l_prefix} anyway. In other
words, it is only a problem if you actually create a true src rpm (with both
bz2 files included), and you want to be able to "build" that package for any
%{l_prefix}.

So while I understand your desire to adhere to your package design
philosophy (install anywhere - even with a "src" package that *doesn't*
build from source), in this case my concern with patching DBD::Oracle (as
well as all other packages that use oracle-barebone) is that the scope of
the problem is unknown (how many packages might be affected?), and I may not
discover this type of problem until it is too late. For example, in our
case, the problem was not detected until a user tried running the new
DBD::Oracle from a machine that did not happen to have a non-OpenPKG Oracle
client installed. And since we're also deploying installed packages to our
entire user community, stability and predictability is very important to us.
So I think we'll be safer to stick with my method for now.

Just FYI, the preferred way to patch DBD::Oracle is to modify the
Makefile.PL. This will involve writing some Perl code - after the script has
discovered the Oracle OCI build rules - to test for the Oracle version and
the OS, and replace "-lclntsh" with "-lclntsh -lwtc9". [I notice that your
oracle import package creates an rc.oracle file with the line
'oracle_libs="-lclntsh -lwtc9"'. Is there a way to use that as part of this
patch?]

BTW, do you have a sense of how many packages you are currently supporting
(or planning to support in the near future) that could be made to rely on
oracle-barebone?

Thanks,
       Dennis

> -----Original Message-----
> From: openpkg-dev-owner@openpkg.org 
> [mailto:openpkg-dev-owner@openpkg.org] On Behalf Of Ralf S. 
> Engelschall
> Sent: Friday, January 30, 2004 10:43 AM
> To: openpkg-dev@openpkg.org
> Subject: Re: New oracle-barebone submission
> 
> 
> On Fri, Jan 30, 2004, Dennis McRitchie wrote:
> 
> > I have just uploaded 
> oracle-barebone-9.2.0.1-20040128.nosrc.rpm to the 
> > contrib area.
> >
> > The only change from the previous version is a critical 
> documentation 
> > change to oracle-barebone.txt: The new instructions now 
> state in part:
> >
> > 3. Also create an empty directory /oracle/OracleHome on the 
> target machine,
> >    also owned by oracle/oracle. Then create a symbolic link 
> to it from
> >    %{l_prefix}/share/oracle-barebone, e.g.,
> >    ln -s /oracle/OracleHome %{l_prefix}/share/oracle-barebone
> >
> > The user is then instructed to use this symbolic link as 
> the path to 
> > use when installing Oracle 9i, instead of using /oracle/OracleHome.
> >
> > The reason for this change is that libclntsh.so is created 
> at install 
> > time (by genclntsh), and records the current ORACLE_HOME as 
> the RPATH 
> > to use when loading for libwtc9.so at run time. Both files are 
> > subsequently moved to %{l_prefix}/share/oracle-barebone. 
> Furthermore, 
> > in programs such as the DBD::Oracle sub-module within the perl-dbi 
> > module, when Oracle.so is built, libclntsh.so is explicitly 
> specified, 
> > but libwtc9.so is not. It is assumed that ORACLE_HOME will not have 
> > changed once Oracle 9i has been installed. So when Oracle.so is 
> > subsequently loaded, the ldd (dynamic loader) on Solaris can't find 
> > libwtc9.so once it has been moved to 
> > %{l_prefix}/share/oracle-barebone. (The dynamic loader on Red Hat 
> > Linux 9 also looks in /oracle/OracleHome, but if it does 
> not find it 
> > there, it then looks in %{l_prefix}/share/oracle-barebone. So 
> > DBD::Oracle works on Linux, but it would be safer if the dynamic 
> > loader did not look in /oracle/OracleHome at all.)
> >
> > The advantage of changing things in oracle-barebone rather than in 
> > perl-dbi is that all users of libclntsh.so will benefit 
> automatically.
> 
> Yes, but is implies that you build the oracle-barebone only 
> for your particular %{l_prefix}. Once you build it for a 
> different one you again went into trouble. And OpenPKG is 
> about "we allow installating into arbitrary filesystem 
> areas", the only real solution is to explicitly link in 
> libwtc9.so in all packages. So I prefer more a patch for 
> DBD::Oracle here, because it is then a universal solution 
> while your symlink approach solves the problem just 
> locally... Nevertheless it is a tricky idea we should mention 
> in the documentation.
> 
>                                        Ralf S. Engelschall
>                                        rse@engelschall.com
>                                        www.engelschall.com
> 
> ______________________________________________________________________
> The OpenPKG Project                                    www.openpkg.org
> Developer Communication List                   openpkg-dev@openpkg.org
> 

______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
Developer Communication List                   openpkg-dev@openpkg.org

[prev in list] [next in list] [prev in thread] [next in thread]