scop
The README file contains misinformation about pkg-config for installation
The README file currently contains about installation:
The recommended directory is
completionsdir, which you can get withpkg-config --variable=completionsdir bash-completion.
However, this is incorrect when using a different prefix from bash-completion. This can have 2 bad effects:
- Installation failure due to insufficient permission (for instance, when the non-root end user wants to install software somewhere under his home directory). This can also be seen with
make distcheck(#265). - As root, e.g. with the default prefix
/usr/local(or a directory under/opt), whose goal is to avoid clashes with the vendor provided files, such files (e.g. from Debian) could be overwritten.
Note that pkgconf (previously pkg-config) is designed to say where things can be found for a build, not where they should be installed. It its man page: "pkgconf is a program which helps to configure compiler and linker flags for development libraries. This allows build systems to detect other dependencies and use them with the system toolchain."
What is said later in the README file, which mentions $PREFIX, should be put here as the recommended solution.
Note that if bash-completion really wants to suggest pkgconf as a way to get an installation directory, I think that this should be a directory relative to $PREFIX, e.g.
completionsdirsuffix=share/bash-completion/completions
so that $PREFIX/$completionsdirsuffix could be used by the package as the installation directory for completions.
That is what the disclaimer means.
From README
Q. I author/maintain package X and would like to maintain my own completion code for this package. Where should I put it to be sure that interactive bash shells will find it and source it?
A. [ Disclaimer: Here, how to make the completion code visible to bash-completion is explained. We do not require always making the completion code visible to bash-completion. In what condition the completion code is installed should be determined at the author/maintainers' own discretion. ]
- insufficient permission (for instance, when the non-root end user wants to install software somewhere under his home directory)
"I author/maintain package X" means a package in the OS distribution and implies sufficient permission. The Q&A is not for non-root end users in general. Nevertheless, in my experience, the permission error at the make install stage wouldn't be a real problem because it just outputs an error message, but maybe that's wrong. I'll check the behavior later.
- As root, e.g. with the default prefix
/usr/local(or a directory under/opt), whose goal is to avoid clashes with the vendor provided files, such files (e.g. from Debian) could be overwritten.
It's recently been changed from /etc to /usr/share/bash-completion (in the case where the target bash-completion is the system one at /usr/share/bash-completion) in PR #1379. I think /etc has been a place where conflicts would be allowed, but there seems to be also movement that "packages shouldn't create anything in /etc" as suggested in PR #1399.
What is said later in the README file, which mentions
$PREFIX, should be put here as the recommended solution.
As written there, $PREFIX is for bash-completion >= 2.12. We recognize that an old version of bash-completion in the market takes 10 years to be replaced.
I'm starting to seriously contemplate simplifying (including removing some of it altogether) the level of support we try to provide for installing 3rd party completion snippets and installing bash-completion in general. There seems to be just too many interpretations and thoughts what's the "correct" way, and the topic recurs too often.
