Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document possible paths for user config #17

Open
bnavigator opened this issue Nov 15, 2021 · 6 comments
Open

Document possible paths for user config #17

bnavigator opened this issue Nov 15, 2021 · 6 comments

Comments

@bnavigator
Copy link
Contributor

Where do I put the user config?

Can I override the paths to the config with an environment variable?

@AdamMajer
Copy link
Member

No, you can't override the path in ENV variable, but maybe that could be a feature.

The user config is ~/.config/libalternatives.conf. It mostly is meant to be managed by alts itself, but you can edit it by hand too.

System-wide overrides is /etc/libalternatives.conf and it's also meant to be managed by alts and the actual root user. It is not to be modified by some random RPM, in case you are wondering.

@bnavigator
Copy link
Contributor Author

I found XDG_CONFIG_HOME in the sources

So what is the syntax for libalternatives.conf? Because calling alts -u mybin ... doesn't write anything to libalternatives.conf.

Here is my use case:
Python packages usually have something like this in their specfile:

%check
%pytest

%pytest expands to a loop callong of pytest-%{%python_bin_suffix} for all active suffixes.

Now sometimes the test suite of a package calls subprocesses and naturally does not know about the flavors. With u-a, I can override this with symlinks like here: https://build.opensuse.org/package/view_file/devel:languages:python:jupyter/python-jupyter-server/python-jupyter-server.spec?expand=1

But somehow this starts to fail here: https://build.opensuse.org/package/show/home:bnavigator:branches:devel:languages:python:jupyter/python-jupyter-server

@AdamMajer
Copy link
Member

Correct, XDG_CONFIG_HOME would be more accurate :-)

alts -n mybin -p <priority> to set something or to clear it

alts -l mybin to list priorities available

@bnavigator
Copy link
Contributor Author

Thanks, it took me some time to realize that <priority> is not a new higher priority number but the entry from available priorities to select. So it is more of a selection, than a priority.

For the record here is what I end up with:

%if %{with test}
%check
export XDG_CONFIG_HOME=$PWD/build/config
%{python_expand # provide libalternatives and u-a links in the correct flavor version
mkdir -p build/config
%if %{with libalternatives}
for b in /usr/share/libalternatives/*; do
  if [ -e "${b}/%{$python_version_nodots}.conf" ]; then
    alts -n $(basename ${b}) -p %{$python_version_nodots}
  fi
done
%endif
mkdir -p build/testbin
for bin in %{_bindir}/*-%{$python_bin_suffix} %{buildroot}%{_bindir}/*-%{$python_bin_suffix}; do
  # four percent into 1 by rpm/python expansions
  mainbin=${bin%%%%-%{$python_bin_suffix}}
  basemain=$(basename ${mainbin})
  if [ "$(readlink ${mainbin})" = "/etc/alternatives/${basemain}" ]; then
    ln -s ${bin} build/testbin/${basemain}
  fi
done
}
export PATH=$PWD/build/testbin:$PATH
%pytest
%endif

@AdamMajer
Copy link
Member

Looks correct, though I'm not sure you need to specify the XDG_CONFIG_HOME unless it's for your test. For alts, it should work without it. If it doesn't, it's a bug.

Yes, the priority refers to the priority a given config (or alternative) is assigned by the RPM developer. Then you can override the default if the highest priority is not what you want. This is similar concept to the priorities in the update-alternatives.

@bnavigator
Copy link
Contributor Author

Pointing XDG_CONFIG_HOME to a directory inside the rpmbuild tree has the advantage that the config gets cleaned after the build. If you have a lingering ~/.config/libalternatives.conf with nonstandard selections, this can pose any kind of problems to packages being built on a local osc build call without the explicit --clean flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants