Using dev-db/oracle-instantclient-sqlplus I find insufficient standardly provided three variables (ORACLE_HOME, LDPATH and TNS_ADMIN). Using only them on my UTF8 localized workstation sqlplus shows '???'s instead of cyrillic symbols when connecteng to non-UTF8 database. After adding to /etc/env.d/50oracle-instantclient-basic config file proper variable: NLS_LANG=RUSSIAN_RUSSIA.AL32UTF8 sqlplus works correctly. But after re-emerge dev-db/oracle-instantclient-basic (last time it was a check for bug #524922) I find /etc/env.d/50oracle-instantclient-basic config overwritten, with restoring three default variables. So, sqlplus client is broken again. Together with resetting all user's settings, it forces usage TNS_ADMIN=/etc/oracle/ Even if user want to change it. I suggest to modify =dev-db/oracle-instantclient-basic-11.2.0.4-r1 to use not one, but two configs: Now present automatically updated /etc/env.d/50oracle-instantclient-basic for (ORACLE_HOME and LDPATH) and just initially created, but never updated /etc/env.d/52oracle-instantclient-basic.extra for TNS_ADMIN and other setting user may need. With proper warning about /etc/env.d/50oracle-instantclient-basic in pkg_postint message.
(In reply to Sergey S. Starikoff from comment #0) > After adding to /etc/env.d/50oracle-instantclient-basic config file proper > variable: > NLS_LANG=RUSSIAN_RUSSIA.AL32UTF8 Would it work for you to put NLS_LANG into either your ~/.profile or even /etc/env.d/99oracle? Same for TNS_ADMIN. > Together with resetting all user's settings, it forces usage > TNS_ADMIN=/etc/oracle/ > Even if user want to change it. The values in /etc/env.d/99oracle-instantclient-basic are intended as defaults, and users (or even projects) override (TNS_ADMIN) or set (NLS_LANG) them somewhere else, like: host: /etc/env.d/99oracle users: ~/.profile project: project environment > With proper warning about /etc/env.d/50oracle-instantclient-basic in > pkg_postint message. While I could add messages, overriding things like above somehow feels like "business as usual", not specific to oracle-instantclient at all, no?
(In reply to Michael Haubenwallner from comment #1) > Would it work for you to put NLS_LANG into either your ~/.profile or even > /etc/env.d/99oracle? Same for TNS_ADMIN. It works even if proper value of NLS_LANG is set as environment variable (just export NLS_LANG=…). And one more: correct setting the NLS_LANG variable is necessary everywhere, when user uses non-default locale. I.e. if user set LINGUAS variable in make.conf, he probably need to setup NLS_LANG. > > Together with resetting all user's settings, it forces usage > > TNS_ADMIN=/etc/oracle/ > > Even if user want to change it. > > The values in /etc/env.d/99oracle-instantclient-basic are intended as > defaults, and users (or even projects) override (TNS_ADMIN) or set > (NLS_LANG) them somewhere else, like: > host: /etc/env.d/99oracle > users: ~/.profile > project: project environment Yes. Maybe only add einfo message on non-default LINGUAS value, that user probably needs to setup proper value of NLS_LANG. Format: NLS_LANG = language_territory.charset For detailed description see http://docs.oracle.com/cd/E11882_01/server.112/e10729/applocaledata.htm And add a header like: # /etc/env.d/99oracle-instantclient-basic # Do not edit this file, to extend/override it's settings use /etc/env.d/99oracle > > With proper warning about /etc/env.d/50oracle-instantclient-basic in > > pkg_postint message. > While I could add messages, overriding things like above somehow feels like > "business as usual", not specific to oracle-instantclient at all, no? Strictly speaking, client default (used in current Gentoo installation) already overrides Oracle's default. TNS_ADMIN for database server (seen just now): /ora/app/oracle/product/11.2.0/dbhome_1/network/admin/ The default for Oracle's Instantclient I don't remember. For non-English languages setting NLS_LANG is really needed.
(In reply to Michael Haubenwallner from comment #1) > The values in /etc/env.d/99oracle-instantclient-basic are intended as > defaults, and users (or even projects) override (TNS_ADMIN) or set > (NLS_LANG) them somewhere else, like: > … > users: ~/.profile > … Maybe mostly as a question for separate bug: For now =sys-apps/baselayout-2.2 don't install /etc/skel/.profile So, default user have to create this file. Also there is a question about shell-compatibility. /etc/profile: # That this file is used by any Bourne-shell derivative to setup the # environment for login shells. Of course, portage requires bash. But are _all_ modern shells bash-compatible?
(In reply to Sergey S. Starikoff from comment #3) > (In reply to Michael Haubenwallner from comment #1) > > The values in /etc/env.d/99oracle-instantclient-basic are intended as > > defaults, and users (or even projects) override (TNS_ADMIN) or set > > (NLS_LANG) them somewhere else, like: > > … > > users: ~/.profile > > … > > Maybe mostly as a question for separate bug: > For now =sys-apps/baselayout-2.2 don't install /etc/skel/.profile > So, default user have to create this file. Eventually yes. However, documenting how to set up users login environment is beyond this package. > Also there is a question about shell-compatibility. > /etc/profile: > # That this file is used by any Bourne-shell derivative to setup the > # environment for login shells. > > Of course, portage requires bash. > But are _all_ modern shells bash-compatible? No, but modern shells are Bourne-shell compatible - which is what /etc/profile does require. That portage's requirement goes beyond Bourne-shell is irrelevant here.
(In reply to Michael Haubenwallner from comment #4) > No, but modern shells are Bourne-shell compatible - which is what > /etc/profile does require. Erm, IIRC /etc/profile is POSIX-compatible for modern shells.
dev-db/oracle-instantclient-12.1.0.2 now does install a template /etc/env.d/99oracle-instantclient when it does not exist, or does copy the old one otherways. However, now having that said, this feels a little awkward... Instead, it would be more correct to let etc-update/dispatch-conf/etc. do that job. But that requires some other location than /etc/env.d/ for the config-file. Anyway, fixed for now.
