The wrapper script /usr/bin/opera overwrites the environment variables OPERA_PERSONALDIR and OPERA_DIR. They should only be set if they were unset. Reproducible: Always Steps to Reproduce: 1. execute in bash: OPERA_PERSONALDIR=~/opera-test-profile opera Actual Results: Opera uses the profile ${HOME}/.opera Expected Results: Opera should use the profile ~/opera-test-profile Possible fix: #!/bin/bash export OPERA_DIR="${OPERA_DIR="/usr/share/opera"}" export OPERA_PERSONALDIR="${OPERA_PERSONALDIR="${HOME}/.opera"}" exec /usr/lib64/opera/opera "$@"
I see why it would matter to set OPERA_PERSONALDIR, so I am inclined to fix that, but I don't get why /usr/bin/opera should use anything else than the default OPERADIR.
I just did it for consistency. It is still possible to change the shared directory using the -sharedir command line option. So I would expect the following two calls behave equally (even if opera fails to start in both cases): opera -sharedir foobar OPERA_DIR=foobar opera But, as you said, in the end there is probably no reason to change the shared directory. I don't know what's more convenient – just do what you think is better.
(In reply to comment #2) > I just did it for consistency. ok. > It is still possible to change the shared directory using the -sharedir command > line option. So I would expect the following two calls behave equally (even if > opera fails to start in both cases): > > opera -sharedir foobar > > OPERA_DIR=foobar opera The -pd <dir> option overrides that as well. > But, as you said, in the end there is probably no reason to change the shared > directory. I wonder if setting these defaults in the wrapper script is necessary at all, now.
OPERA_DIR needs to be set, and I hesitate to set it to anything else than the share dir that is installed with the wrapper script. However, OPERA_PERSONALDIR now defaults to $HOME/.opera, so I have changed the ebuilds not to set that in the wrapper script any longer. Thank you for reporting.
