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