Post by M. ZhouPost by Blair NoctisKind of a shameless plug, but enough people said it's useful so I thought might as well let more know.
https://manpages.debian.org/unstable/dh-shell-completions/dh_shell_completions.1.en.html
https://salsa.debian.org/debian/dh-shell-completions
Thank you for this dh module! After browsing the examples, I came up with
an old problem about these completion scripts -- whether the completions
should be loaded by default, and whether that behavior should be synced
among shells.
Completions are static (relative to a specific version of the program).
There seems no need to modify them.
There seems no need to disable them.
They don't seem to cause harm.
So I don't think enabling them by default would cause any trouble.
Different shells could have different conventions.
But the status quo is, to my knowledge,
most packages just install completions as immediately enabled.
I don't think such differences, even if they exist, matter anymore.
Post by M. ZhouDo you think it is useful to define some flags for
dh_shell_completions, like --enable-by-default, --disable-by-default
to decide whether a completion file should be enabled by default.
I'm raising this question because I find it somewhat confusing
because different shells do the completions and keybindings in very
https://salsa.debian.org/go-team/packages/fzf/-/blob/master/debian/README.Debian
As you can see, key-binding scripts are similar to completion scripts.
Maybe they can be dealt by the same dh module as well. Generally
key-binding scripts should not be enabled by default due to potential
conflicts.
At a glance yes.
But install keybindings where?
Shells have standard locations in which completions are immediately enabled.
Keybindings obviously shouldn't be immediately enabled.
But are there such standard locations for "disabled" keybindings?
Your example didn't show existence of such.
If not, where should we install them to?
Maybe we can install them as docs or examples,
but then a debian/$package.{docs/examples} would do.
Also, the package name is already there.
I'd rather something named "shell-completions",
not handle things other than, well, shell completions.
Post by M. ZhouA quick search suggests that both policy and devref do not cover
the shell integration topic.
An example that resembles what I'm talking about is dh_installsystemd.
It has --no-enable, --restart-after-upgrade, --no-restart-after-upgrade,
etc flags to control the systemd unit behavior upon dpkg actions.
There are also packages with service definitions that can't be used as is.
Or even unwanted by the user.
They can at most be installed as docs or examples.
IMO this situation is akin to keybinding scripts.
--
Sdrager,
Blair Noctis