On Thu, Jan 29, 2015 at 2:14 PM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > On Sun, 2015-01-25 at 13:42 +0200, Ville Skyttä wrote: >> Fall back to the previous /etc/bash_completion.d dir on failures >> (either old bash completion or not installed). >> >> Signed-off-by: Ville Skyttä <ville.skytta at iki.fi> >> --- >> Makefile.am | 2 +- >> configure.ac | 6 ++++++ >> 2 files changed, 7 insertions(+), 1 deletion(-) > > Thanks for the patch! We already have an earlier proposal, though: > https://bugs.freedesktop.org/show_bug.cgi?id=84921 > > As I explained in the bug, I don't like using bash-completion.pc, > because it will give a directory that will make us overwrite distro > files, It's not quite that clear cut. If installing on a system that has bash-completion built and installed from source without any special settings given, it will give a /usr/local directory for installing completions, specifically /usr/local/share/bash-completion/completions. In any case, it will give the *correct* directory where to install the completions to. If we (we = bash-completion) did have support for both let's say /usr/share and /usr/local/share bash completions dirs, we'd want to expose both of those through our *.pc and have people use it to get the locations, but they'd need to be two variables and how would the build system of let's say pulseaudio know which one to use (assuming it wouldn't be asked from the user)? Anyway, I don't think the possibility to install into system locations if bash-completion.pc so says is an issue (and in any case it's a smaller problem than installing into the deprecated and eagerly loaded /etc/bash_completion.d), and I'm not convinced that adding another dir where to load them from would be a clear improvement overall. By the way, where to load completions from is a bash-completion (not bash) thing, they're separate projects.
