[PATCH] build-sys: Install bash completion to where bash-completion.pc says

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux