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