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

[Axel Beckert]

Hi Frank,

thanks a lot for trying to wrap the history of all these directories!
I wasn't aware of this non-obvious timeline with Debian having added
vendor-* directories before upstream last updated their search paths.

> The reason  this doesn't  get added  on Debian right  now is  that we're
> still  setting ‘--enable-site-fndir=/usr/local/share/zsh/site-functions’
> explicitly. Dropping this setting would change this.

I see.

> Since  Debian's ‘vendor-*’  directory handling  predates this  by years,
> changing this,  effectively adding  a second path  for the  same purpose
> seems inelegant, since it adds redundancy where none is needed.

I agree here.

> This however, sucks:
> 
> % apt-file search usr/share/zsh/site-functions/ | wc -l
> 30
> 
> Because that is thirty functions that will not work.

Ack.

> When we  added the ‘vendor-*’ stuff,  we filed bug reports  for packages
> that  tried this,  because  even  back then,  it  wouldn't have  worked,
> because site-functions always was in /usr/local with Debian's zsh.
> 
> That resulted in this:
> 
> % apt-file search vendor-completions | wc -l
> 166

This is clearly the majority. (IMHO) Good.

> I am  not sure if  there's an elegant way  to resolve this,  because the
> ‘vendor-*’ directories  are the documented  way for zsh packages  to add
> functions for more than a decade. I  don't think dropping them is a good
> idea, because it would break backward compatibility. And as I said, just
> adding the second  --prefix based site-functions entry  would litter the
> system by added multiple destinations for the same purpose.
> 
> Maybe there's a way to add a  lintian check for the installation path of
> zsh function files in Debian packages.

Good idea! I can work on this.

> With that, we could add the prefix based site-functions directory,
> but deprecate its use.

Ack, that thought came to me also after having read your mail
half-through. It though has the danger that some so far not active
plugins will suddenly start to work. So we add least need to
debian/zsh.bug-script.

Currenty it only checks for packages that ship files in
/usr/share/zsh/vendor-completions/ and
/usr/share/zsh/vendor-functions/.

> That way, packages that disrespect the zsh package's policy still
> work, while keeping the possibility of a clean system, in case all
> package adhere to the policy. We could file a bunch of bugs for the
> packages that are currently using /usr/share/zsh/site-functions
> right now.

Debian prefers lintian warnings over mass bug filing. Mass bug filing
needs to be discussed on the debian-devel mailing list first.

What I now still wonder to (hopefully) address Joey's issue:

Is there a way to build the Debian zsh (respectively probably the
zsh-dev) package in a way so that locally installed Zsh extensions get
cleanly installed into /usr/local/ while Debian packages still install
stuff to /usr/ (preferably these vendor-* directories)?

I wonder if something like a dh_zsh helper could help here (i.e. for
the vendor-* directory part) as well.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE