[Pkg-zsh-devel] Bug#934926: overridding of default fpath causes uncessary complexity and pain for software providing zsh completions

[Simon McVittie]

On Fri, 16 Aug 2019 at 19:00:48 +0000, Daniel Shahaf wrote:
> Joey Hess wrote on Fri, 16 Aug 2019 18:35 +00:00:
> > By default zsh loads completions from /usr/share/zsh/site-functions
> > and while the name of that is perhaps not great, as it's not
> > site-specific[1], it's a standard location. Debian has overridden this,
> > so zsh does not look there, but instead in
> > /usr/share/zsh/vendor-functions and /usr/share/zsh/vendor-completions
> ...
> > The rationalle for the change in #620452 seems too weak to justify this
> > added complexity. zsh could at least continue looking in the default
> > location as well as whatever other locations Debian wants to patch in.
> 
> So /usr/local/share/zsh/site-functions is still there for stuff installed
> by the administrator, and vendor-functions and vendor-completions are
> added in there for stuff provided by other Debian packages.  Are you
> just asking to re-add ${PREFIX:-/usr}/share/zsh/site-functions there,
> presumably between the first and second elements?

I am not the original reporter of this bug, but: yes, I think it would
be pragmatic for Debian's zsh to search /usr/share/zsh/site-functions.
It should be searched after /usr/local/share/zsh/site-functions, and at
a similar priority to vendor-functions and vendor-completions (I think
either immediately before or immediately after those would be fine).

zsh doesn't seem to provide a way for packages' build systems to discover
what directory they are meant to install completions into (unlike
bash-completion, which provides /usr/share/pkgconfig/bash-completion.pc
which can be queried for a completionsdir variable), so upstream source
code for packages that want to install zsh completions will typically
install to ${datadir}/zsh/site-functions by default. I don't think it
scales well to insist that every upstream package that wants to install
zsh completions should have a --with-zshcompletiondir configure option
(or equivalent), and that every Debian package that installs zsh
completions must explicitly override the installation directory in
d/rules or in d/*.install.

The simplest way to resolve this would be for Debian's zsh to search
/usr/share/zsh/site-functions as Joey requested. That way, packages with
zsh completions, such as bluez, would not need to do anything special.

I realise the Debian zsh maintainers want to use a directory with a less
misleading name, but it seems we currently have 26 packages in unstable
that get this wrong, and if I hadn't tested with zsh before uploading,
the next version of bubblewrap would have been the 27th:

$ apt-file search --filter-suites=unstable /usr/share/zsh/site-functions
arch-install-scripts: /usr/share/zsh/site-functions/_archinstallscripts
bluez: /usr/share/zsh/site-functions/_bluetoothctl
cpu-x: /usr/share/zsh/site-functions/_cpu-x
draai: /usr/share/zsh/site-functions/_draai
elogind: /usr/share/zsh/site-functions/_loginctl
flameshot: /usr/share/zsh/site-functions/_flameshot
flightgear: /usr/share/zsh/site-functions/_fgfs
foot: /usr/share/zsh/site-functions/_foot
foot: /usr/share/zsh/site-functions/_footclient
gallery-dl: /usr/share/zsh/site-functions/_gallery-dl
gpaste: /usr/share/zsh/site-functions/_gpaste-client
guix: /usr/share/zsh/site-functions/_guix
kdeconnect: /usr/share/zsh/site-functions/_kdeconnect
kickpass: /usr/share/zsh/site-functions/_kickpass
laminarc: /usr/share/zsh/site-functions/_laminarc
libinput-tools: /usr/share/zsh/site-functions/_libinput
lr: /usr/share/zsh/site-functions/_lr
nvme-cli: /usr/share/zsh/site-functions/_nvme
pcp: /usr/share/zsh/site-functions/_pcp
pencil2d: /usr/share/zsh/site-functions/_pencil2d
polybar: /usr/share/zsh/site-functions/_polybar
polybar: /usr/share/zsh/site-functions/_polybar_msg
profile-sync-daemon: /usr/share/zsh/site-functions/_psd
vifm: /usr/share/zsh/site-functions/_vifm
wlogout: /usr/share/zsh/site-functions/_wlogout
xe: /usr/share/zsh/site-functions/_xe

This is nearly 20% of the list of 138 packages in unstable that install
files into /usr/share/zsh, so if it's an error, then it is a common error.

https://bugs.launchpad.net/ubuntu/+source/borgbackup/+bug/1827232 is a good
example of a package that historically got this wrong and was subsequently
fixed, taking up various people's time in the process.

Or, if the Debian zsh maintainers' policy is that installing to
/usr/share/zsh/site-functions is always wrong, then we should have a
Lintian check that flags it as a packaging error and recommends using
vendor-completions or vendor-functions instead, and bug reports against
the 26 packages listed above (the only ones I have checked are bluez
and nvme-cli, for which I've confirmed that the zsh completions are
non-functional at the moment).

If there are other directories that are commonly used by upstream software
but are considered wrong in Debian, then those should be covered by the
same Lintian check.

> I suppose that if we add this, we should also add
> ${PREFIX}/share/zsh/${ZSH_VERSION}/functions, shouldn't we?

It seems unlikely that third-party software will install into
${datadir}/zsh/${ZSH_VERSION}/functions, because it would have to go out
of its way to discover the current zsh version, and then would cease
to work whenever zsh is upgraded. So I don't think this is necessary
or desirable.

    smcv