[Pkg-zsh-devel] Bug#776663: Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Axel Beckert]

Hi Frank and Tim,

Frank Terbeck wrote:
> Tim Booth wrote:
> > This is a request on behalf of Bio-Linux and the Debian Med
> > developers. The attached file shows the zshrc used on Bio-Linux, and
> > the part we'd really like to see in the standard zsh-common package is
> > support for a zprofile.d configuration directory[...]
> 
> Is there a specific problem you'd like to address?

I'd be curious about Tim's reason, too. I see, he (co-)maintains quite
a lot of packages in Debian, but nothing which strikes me as
zsh-related.

Oh, and I'm glad we're having that discussion in a bug report! So I'm
not the only one who thought about such a feature! ;-) (SCNR)

> I'm not a big fan of these kitchen sink directories everybody and
> their dog gets to dump stuff into.

I'm actually quite a big fan of them (otherwise I probably never would
have written Run::Parts[1]). They make packaging extensions, addons,
plugins, etc. way easier as there's no need to modify the
configuration files of other packages (which is forbidden by Debian's
Policy).

  [1] https://packages.qa.debian.org/libr/librun-parts-perl.html
      https://metacpan.org/release/Run-Parts

See e.g. /etc/apache2/*-enabled/, /etc/apt/apt.conf.d/ or
/etc/bash_completion.d/ for examples used successfully by many
packages. And I recently saw that /etc/apt/preferences.d/ is actively
used by apt-listbugs to hold packages with RC bugs via pinning.

Another nice example which would be much easier that way is the
planned packaging grml's zshrc. (Which is still on my TODO list.)

As far as I know we already have /usr/share/zsh/vendor-functions and
/usr/share/zsh/vendor-completions (of which only the latter is used so
far), but that doesn't cover startup files like zshrc, zprofile,
zshenv, etc.

> Especially in “/etc” since it's kind of hard for a package to remove
> stuff from there again.

Huh? I'm sorry, but I have no idea what kind of issues you might refer
to. If it's a "conffile" coming from a package, dpkg handles that
well. If it's a generated file there's ucf to properly handle it. So
I'd be happy if you could elaborate that issue a little bit as I'd be
curious to learn about issues I'm not yet aware of.

The common argument against .d directories with configuration snippets
so far seemed performance issues to me.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://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