Created attachment 386350 [details] oracle-instantclient-basic-12.1.0.2.ebuild Second version of Oracle 12 client. To my mind it's a time to commit it into tree.
Created attachment 386352 [details, diff] 12.1.0.2-makefile.patch 12.1.0.2-makefile.patch for oracle-instantclient-basic-12.1.0.2.ebuild
Created attachment 386354 [details] oracle-instantclient-sqlplus-12.1.0.2.ebuild
Any ETA when we can expect a bump (includig SDK)?
(In reply to Thomas D. from comment #3) > Any ETA when we can expect a bump (includig SDK)? AFAIR it's expected that you'll vote for this bug's fix. P.S.: This commit should also include fix of bug #527594 (short summary: don't use "system" /etc/env.d/50oracle-instantclient-basic for keeping custom configuration directives, for them you should create separate config file, something like /etc/env.d/99oracle-instantclient-basic).
I'm thinking about moving the installation path from /usr/$(get_libdir)/oracle/11.2.0.4/client/ to /opt/oracle-instantclient/ Thoughts?
No objections, looks like the package is similar to Oracle J{RE,DK}. Then we should also consider renaming to dev-db/oracle-instantclient-{basic,sqlplus}-bin and should use install path /opt/$P That's how dev-java/oracle-j{re,dk}-bin are named/installed.
Renaming to *-bin feels needless, as there is no non-bin variant available. Installing to /opt/$P feels needless as well, as I do not see need for SLOTting oracle-instantclient. Also this would require an eselect-module to choose a "current" one. Agreed this is confusing, but except for the name of the company providing the packages these days, oracle-instantclient is a completely different kind of package than oracle-jdk/jre is.
(In reply to Michael Haubenwallner from comment #5) > I'm thinking about moving the installation path > from /usr/$(get_libdir)/oracle/11.2.0.4/client/ > to /opt/oracle-instantclient/ > > Thoughts? Moving proprietary (no sources available) library to /opt looks reasonable. For me better path will be: /opt/oracle/version-$(arch)/instantclient/ /opt/oracle/version-$(arch)/sqlplus … (In reply to Michael Haubenwallner from comment #7) > Installing to /opt/$P feels needless as well, as I do not see need for > SLOTting oracle-instantclient. Also this would require an eselect-module to > choose a "current" one. Looking at Oracle developer (keeping clients from 9, 10 and 11 Databases) I see, that in some cases slotting of Oracle Client per primary Database version may be reasonable. Although complex and rarely needed.
(In reply to Sergey S. Starikoff from comment #8) > (In reply to Michael Haubenwallner from comment #5) > > I'm thinking about moving the installation path > > from /usr/$(get_libdir)/oracle/11.2.0.4/client/ > > to /opt/oracle-instantclient/ > > > > Thoughts? > > Moving proprietary (no sources available) library to /opt looks reasonable. > > For me better path will be: > /opt/oracle/version-$(arch)/instantclient/ > /opt/oracle/version-$(arch)/sqlplus While I agree /opt/oracle/ seems reasonable, this often is the installation path of the real database server. OTOH, when there is a database server installed, there might be no need for the instantclient then. Why would you need "version-$(arch)"? And no, sqlplus will not go into some separate directory, but to somewhere into instantclient/bin/ instead. > (In reply to Michael Haubenwallner from comment #7) > > Installing to /opt/$P feels needless as well, as I do not see need for > > SLOTting oracle-instantclient. Also this would require an eselect-module to > > choose a "current" one. > > Looking at Oracle developer (keeping clients from 9, 10 and 11 Databases) I > see, that in some cases slotting of Oracle Client per primary Database > version may be reasonable. > Although complex and rarely needed. Hmm - while the .zip files unpack to ./instantclient_12_1/, the .rpm files would install to /usr/lib/oracle/12.1/client{,64}/, which seems to be the reason for the current location in /usr/lib*/ So eventually we should not invent something new, but follow the .rpm locations as far as reasonable instead (and keep it in /usr/lib*/)?
(In reply to Michael Haubenwallner from comment #9) > While I agree /opt/oracle/ seems reasonable, this often is the installation > path of the real database server. OTOH, when there is a database server > installed, there might be no need for the instantclient then. I've missed something and procedure of Oracle Database installation was described in ebuild format? Or Gentoo supports out-of-portage installed applications? > Why would you need "version-$(arch)"? arch to display arch of installed client. Version — option to differ version. For future, if we'll decide to add slots for Oracle client. > And no, sqlplus will not go into some separate directory, > but to somewhere into instantclient/bin/ instead. Maybe, I don't remember defails of installation of sqlplus. Probably we'll also need a symlink to the binary somewhere in standard ${PATH}. > > (In reply to Michael Haubenwallner from comment #7) > So eventually we should not invent something new, but follow the .rpm > locations as far as reasonable instead (and keep it in /usr/lib*/)? If follow rpm, we should stay in /usr installation. Possibly asking upstream about accordance path's idea with FHS.
(In reply to Sergey S. Starikoff from comment #10) > (In reply to Michael Haubenwallner from comment #9) > > While I agree /opt/oracle/ seems reasonable, this often is the installation > > path of the real database server. OTOH, when there is a database server > > installed, there might be no need for the instantclient then. > > I've missed something and procedure of Oracle Database installation was > described in ebuild format? Nope, completely independent of Gentoo: I've just seen machines where the Oracle Database was installed in /opt/oracle. > Or Gentoo supports out-of-portage installed applications? "support" feels wrong as term here, use "allow" or "not hinder" instead. > > And no, sqlplus will not go into some separate directory, > > but to somewhere into instantclient/bin/ instead. > Maybe, I don't remember defails of installation of sqlplus. > Probably we'll also need a symlink to the binary somewhere in standard > ${PATH}. The rpm indeed does create the /usr/bin/sqlplus symlink. > > > (In reply to Michael Haubenwallner from comment #7) > > So eventually we should not invent something new, but follow the .rpm > > locations as far as reasonable instead (and keep it in /usr/lib*/)? > > If follow rpm, we should stay in /usr installation. > Possibly asking upstream about accordance path's idea with FHS. Well, even Gentoo does not (necessarily) follow FHS.
Instead of the multiple dev-db/oracle-instantclient-{basic,sqlplus,odbc,jdbc} packages I'm going to bump as one single dev-db/oracle-instantclient package with USE flags "+sdk +sqlplus odbc jdbc tools" instead (with "tools" for the new Workload Relay Client). For a transition period, the multiple packages will exist in version 12 as empty packages with appropriate USE-dependency on the single package.
(In reply to Michael Haubenwallner from comment #12) dev-db/oracle-instantclient-12.1.0.2 should work now, the old package names still are available.
Is there any chance we can get version 11.2.0.4 in the single ebuild? I am afraid this version will be gone when the transitional packages get removed.
(In reply to Andrew Udvare from comment #14) > Is there any chance we can get version 11.2.0.4 in the single ebuild? I am > afraid this version will be gone when the transitional packages get removed. Do you have a specific reason for why you need 11.2.0.4?
Now with Andrew CC: Do you have a specific reason for why you need 11.2.0.4?
(In reply to Michael Haubenwallner from comment #16) > Now with Andrew CC: Do you have a specific reason for why you need 11.2.0.4? Company I am working with has not yet upgraded and has no immediate plans to do so, unless Oracle declares version 11 completely dead.
(In reply to Andrew Udvare from comment #17) > Company I am working with has not yet upgraded and has no immediate plans to > do so, unless Oracle declares version 11 completely dead. When talking about upgrade plans you're talking about server upgrades, no? As far as I am aware of, there is no problem connecting to an 11 version server using a 12 version client. So unless you really have a problem that breaks with the 12 version client but works with the 11 version client, I still don't see a reason to keep old clients anytime longer than usual.
(In reply to Michael Haubenwallner from comment #18) > (In reply to Andrew Udvare from comment #17) > > Company I am working with has not yet upgraded and has no immediate plans to > > do so, unless Oracle declares version 11 completely dead. > > When talking about upgrade plans you're talking about server upgrades, no? > > As far as I am aware of, there is no problem connecting to an 11 version > server using a 12 version client. > > So unless you really have a problem that breaks with the 12 version client > but works with the 11 version client, I still don't see a reason to keep old > clients anytime longer than usual. Sorry I was not aware these are backward compatible. I upgraded and tested and everything works fine.
