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

[Frank Terbeck]

Tach Axel,

Axel Beckert wrote:
> 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 actually though that this had been discussed before, but I couldn't
find a previous discussion. The instance I was recalling was a about
sourcing stuff from /etc/profile and /etc/profile.d/ itself (see below).


>> 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.

The bash_completions thing is only there because bash doesn't have sane
autoloadable functions. The apache directories I find rediculously
messy.

The apt-usecase seems legit.

With respect to shells, I usually find that applications, that need to
inject code into a user's shell to be by and large mis-designed.

Something that *might* make sense is to source stuff from /etc/profile
and “/etc/profile.d/” in POSIX-mode. See ¹, a mail about that from 2011.
Nobody cared enough to reply; which I guess that tells you something
about the urgency of the situation. ;-)

But like the mails says, even if we did that, it's hard to decide what
because it's not used for portable purposes alone. The bash completion
thing is sourced from there, which other POSIX shells will have a major
problem with.

I think the situation is messy and I'd like to not get my hands dirty.
This is, however, my personal opinion and does by no means reflect the
opinion of the rest of Debian's zsh packaging team. :-)


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

Grml's zshrc could replace the existing configuration. It has everything
Debian's zshrc has and just piles up on that.


> 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.

Yeah, those are used for completely different purposes, though. And
adding them comes at virtually no additional costs.


>> 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.

(*puts on grml-zshrc hat*) As I recall, with grml's zsh configuration,
we had a ton of stuff in /etc/zsh/... and for some reason (I'm not
familiar with any particulars in the developer reference), we couldn't
just remove them in a maintainer script.

It was a huge pain in the ass and for quite a while we had code in the
setup that checked for the existence of old files in those directories,
asking the user to consider removing them. (*puts off hat again*)

To my understanding, stuff in /etc is considered a configuration file,
that might have been changed or added by the user and can therefore not
be removed by packages.  I could see using checksums to gauge whether or
not a file is still in mint condition. I don't know if that is being
done by dpkg these days.


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

My main issue with it is littering.

Performance is a true concern (my personal config file is split up into
multiple files and it not even funny - I'm putting off merging it into
one file again for a while now), though. Albeit not my primary one.


Regards, Frank

¹ http://lists.alioth.debian.org/pipermail/pkg-zsh-devel/2011-October/000248.html

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925