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

[Daniel Shahaf]

Axel Beckert wrote on Sun, Jan 09, 2022 at 08:52:04 +0100:
> Daniel Shahaf wrote:
> > […], or /etc/zsh/zshrc.d/ could be added (there's a separate ticket
> > for that but my quick grep didn't find it),
> 
> You probably had https://bugs.debian.org/776663 in mind which has been
> filed against zsh-common, not zsh (but src:zsh), so I suspect you
> haven't it found because of that.
> 

Indeed.  Thanks.  (I didn't pass «--source» to querybts(1).)

> I'd though would like to see a consensus inside the Debian Zsh team on
> how (and where) to go forward. I'd especially would be happy to hear
> about Frank's (Cc'ed) opinion as he and Daniel are those who are most
> clued about upstream things and especially upstream conventions. (And
> because I know that Frank has a quite clear opinion on #776663 — where
> I actually do have an opinion, too, albeit a different one than Frank.)

Well, if I were designing things from scratch, I'd probably go for
having packages in Debian install to /usr/share/zsh/foo whatever their
upstreams install by default to /usr/local/share/zsh/foo.  That'd be
exactly analogous to Debian's semantics of /usr/bin v. /usr/local/bin
("owned by packages" v. "owned by the local sysadmin") and would result
in short, readable package build scripts (basically just the equivalent
of «./configure --prefix=/usr»).

However, /usr/share/zsh/vendor-* exist, and I see no reason to break
working code.  I suppose we could deprecate these two dirs but not
actually drop support for them before zsh 6.0.  In lintian terms,
I suppose that means a ≤info lintian check for zsh 5.x and a ≥warning
lintian check for zsh 6.x.

And for upstreams… well, that's a discussion I'd rather have upstream.

Cheers,

Daniel