Fix regression in install-data-hook, support sourcing bash_completion.d from /usr/share/ and move ours

[bluca]

In distributions we are in the process of moving data shipped
by upstream projects to /usr/ and out of /etc/, as the latter
is really meant to be for local changes, not for upstream
projects to ship programs/data.

Add support for sourcing compat scripts from /usr/share/bash_completion.d/
together with /etc/bash_completion.d, and move 000_bash_completion_compat.bash
to the former.

[akinomyoga]

This is related to the discussion at #1329 (comment).

I don't think-/usr/share/bash_completion.d/ is the right directory. It should be somewhere under /usr/share/bash-completion/ just like the completions for each command is arranged in /usr/share/bash-completion/completions/. Also, the naming of xxx.d should have come from /etc/profile.d, so it is not a naming convention used under /usr/share.

In distributions we are in the process of moving data shipped
by upstream projects to /usr/ and out of /etc/, as the latter

I'm not familiar with the recent movements in distributions, but which distributions are you referring to? For example, /etc/profile.d seems to be still widely used. Are these removed from most Linux/BSD/etc distributions in the future? Or are you talking about a specific distribution?

[bluca]

This is related to the discussion at #1329 (comment).

I don't think-/usr/share/bash_completion.d/ is the right directory. It should be somewhere under /usr/share/bash-completion/ just like the completions for each command is arranged in /usr/share/bash-completion/completions/. Also, the naming of xxx.d should have come from /etc/profile.d, so it is not a naming convention used under /usr/share.

Sure, I've changed it to /usr/share/bash-completion/compat/, let me know if you prefer a different name.

In distributions we are in the process of moving data shipped
by upstream projects to /usr/ and out of /etc/, as the latter

I'm not familiar with the recent movements in distributions, but which distributions are you referring to? For example, /etc/profile.d seems to be still widely used. Are these removed from most Linux/BSD/etc distributions in the future? Or are you talking about a specific distribution?

For example in Debian we recently moved most program's own shell completion scripts from /etc/bash_completion.d/ to /usr/share/bash-completion/completions/

You can find a list of similar efforts at uapi-group/specifications#76

[akinomyoga]

For example in Debian we recently moved most program's own shell completion scripts from /etc/bash_completion.d/ to /usr/share/bash-completion/completions/

You can find a list of similar efforts at uapi-group/specifications#76

This doesn't seem to be the official decision led by the maintainers of Debian's base system (that covers the basic parts of /etc, including /etc/profile.d). The provided link to a discussion in uapi-group doesn't seem to mention Debian, and the relationship between "The Linux Userspace API Group" (UAPI) and Debian is unclear. I searched for The Linux Userspace API Group "Debian" in Google, and it points to this discussion, which exactly talks about /etc in Debian but with some tension. I also found and read Debian#1051371, where some tensions happened again. The original post of this PR started with "In distributions we are ...", and another comment contained "For example in Debian we recently moved ...", which sounded as if this is the movement led by the main maintainers of major distributions (or Debian) under the general consensus. Also, I wonder why only a link to the UAPI discussion was provided, while the links to the Debian discussions were not. I feel this PR is unconsciously trying to mislead and put pressure on us. People do this when they anticipate that the PR might not be convincing after honest discussions, which itself isn't bad but certainly makes us wary. Also, I do not find mentions about completion scripts in the provided link to a UAPI discussion or the search in Debian's mailing lists. Another thing is that the migration from /etc/bash_completion.d to /usr/share/bash-completion/completions is not necessarily for the proper /etc arrangement, but rather, we've recommended this for the newer bash-completion API. I cannot confirm that the main reason for the mentioned migration to bash-completion/completions was indeed the /etc policy. Actually, this migration should happen in the upstream projects that provide the completion scripts (rather than at the packaging stage in the Debian distribution) because it requires rewriting of the completion scripts using the new API. I shall assess this PR by looking at the code changes genuinely.

[akinomyoga]

I think one thing I should point out is that the /etc/bash_completion.d is anyway for backward compatibility (although there is a subtlety as discussed in #1329 (comment)). Then, a naive question would be whether we should introduce incompatible changes in the code kept for backward compatibility (which doesn't seem to make sense at first glance). If it breaks the compatibility, we could also argue that compatdir should rather be removed.

• To completely get rid of /etc/bash_completion.d, all the programs that provides completion scripts with the old API need to be updated or adjusted in the packaging stage.
• If the change is only applied at the packaging stage of distributions (without updating the scripts to use the new API), the package maintainers can always adjust the location of the scripts (including 000_bash_completion_compat.bash) by setting a system default BASH_COMPLETION_COMPAT_DIR (or applying a patch to bash_completion).
• If an upstream project of a specific command has a chance to change the location of the default install location from /etc/bash_completion.d to another place, it should rather update its completion script to use the newer API and put it in /usr/share/bash-completion/completions.
  • In this context, if the project author sets up the installation of the completion script using autoconf or cmake following our README.md, if we change the compatdir in pkg-config, the installation location should automatically be adjusted even if the project is not actively maintained. In this sense, changing the default location of compatdir now still has some effects. A little concern is how widely our pkg-config settings are installed in the system in distributions.

Even if this PR doesn't have much benefits in the practical situations, I think I can accept the PR.

[bluca]

This doesn't seem to be the official decision led by the maintainers of Debian's base system (that covers the basic parts of /etc, including /etc/profile.d).

Yes, I mentioned them as separate and independent examples as I thought you were looking for more than one occurrence, sorry for the confusion

[bluca]

If it breaks the compatibility, we could also argue that compatdir should rather be removed.

My intention here was to keep backward compatibility intact - the existing directory is still checked for scripts. Do you see any use case that would be broken by these changes?