Bug#934926: overridding of default fpath causes uncessary complexity and pain for software providing zsh completions
On Fri, 16 Aug 2019 at 19:00:48 +, 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
>
Bug#934926: [Pkg-zsh-devel] Bug#934926: overridding of default fpath causes uncessary complexity and pain for software providing zsh completions
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.
Let's see:
$ /usr/bin/zsh -fc 'print -rl $fpath' | head -3 # that's the Debian
package, 5.7.1-1
/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor-functions
/usr/share/zsh/vendor-completions
$ /srv/zsh/bin/zsh -fc 'print -rl $fpath' | head -3 # that's zsh compiled from
upstream with --prefix=/srv/zsh
/usr/local/share/zsh/site-functions
/srv/zsh/share/zsh/site-functions
/srv/zsh/share/zsh/5.6.2-test-2/functions
$
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?
On the one hand, it _would_ be consistent with upstream, but on the
other hand, nobody should be putting anything in a site-functions
directory under /usr/share (admins should be putting their
customizations in /usr/local/share; other Debian packages should be
putting their stuff in vendor-functions or vendor-completions). I don't
have a strong opinion on this, so I'll defer to others to make the call.
I suppose that if we add this, we should also add
${PREFIX}/share/zsh/${ZSH_VERSION}/functions, shouldn't we?
Cheers,
Daniel
Bug#934926: overridding of default fpath causes uncessary complexity and pain for software providing zsh completions
Package: zsh Version: 5.7.1-1 Severity: normal 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 This means that, as a developer of software that has zsh completions, I first had to learn that the Debian location, which I had made my software's Makefile install to, is non-standard (which took a while since I use Debian everywhere). Then I had to grapple with the question of how to deal with this inconsistency; should I try to probe if it's a Debian system or what? For me this involved looking at how several other Debian packages that ship files in /usr/share/zsh/vendor-completions got them there. I learned that few upstream software packages bother to probe for the correct location, the one I found that does probe does so in a way that would not work if building the software with zsh not installed. I concluded a build system option and documentation was the sanest approach for my software. The Debian package of my software will need to use that in its debian/rules. 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. -- Package-specific info: Packages which provide vendor completions: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=--=== ii borgbackup1.1.10-2 amd64deduplicating and compressing backup program ii curl 7.65.1-1 amd64command line tool for transferring data with URL syntax ii git-annex 7.20190129-3 amd64manage files with git, without checking their contents into git ii meson 0.51.1-1 all high-productivity build system ii mpv 0.29.1-1 amd64video player based on MPlayer/mplayer2 ii ninja-build 1.9.0-2 amd64small build system closest in spirit to Make ii pulseaudio12.2-4amd64PulseAudio sound server ii restic0.9.4+ds-2+b1 amd64backup program with multiple revisions, encryption and more ii systemd 241-7 amd64system and service manager ii systemd-container 241-7 amd64systemd container/nspawn tools ii torsocks 2.3.0-2 amd64use SOCKS-friendly applications with Tor ii udev 241-7 amd64/dev/ and hotplug management daemon ii vlc-bin 3.0.7.1-3 amd64binaries from VLC ii youtube-dl2019.07.02-1 all downloader of videos from YouTube and other sites dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/ -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zsh depends on: ii libc6 2.28-10 ii libcap2 1:2.25-2 ii libtinfo6 6.1+20190713-1 ii zsh-common 5.7.1-1 Versions of packages zsh recommends: ii libc6 2.28-10 ii libncursesw6 6.1+20190713-1 ii libpcre3 2:8.39-12 Versions of packages zsh suggests: pn zsh-doc -- no debconf information -- see shy jo [1] per the FHS, the actually site-specific directory is /usr/local/share/zsh/site-functions, which zsh also looks in signature.asc Description: PGP signature
