[Pkg-zsh-devel] state of RFP: grml-zsh-config?

[Axel Beckert]

Control: block -1 by 776663
Control: tag 776663 + patch

Hi Thomas,

Thomas Koch wrote:
> sorry, I wanted to ask you on Saturday: What's the state of the grml-zsh-config 
> packaging for Debian? Could you provide a braindrop of the problems you're 
> aware of and what discussions have happened?

We recently (like a month ago or so) had the topic on #pkg-zsh in
Freenode, but with no real outcome from my point of view.

There are basically two open issues:

* Upstream should separate grml-zshrc from grml-etc-core. I'm
  willing to help there (see https://github.com/xtaran/grml-zshrc),
  but it seemed if not all upstream devs were happy with that and
  hence nothing happened here.

  Of course I could just take single files out of upstream's release
  and make them into a fake upstream .orig.tar.gz -- but that would
  double the effort as upstream bases on Debian and IMHO it would be
  awkward, if there would be a grml-zshrc in Debian which grml can't
  use.

* I'm still not sure if the zsh package actually offers a place to
  load the grml zshrc globally. I proposed some run-parts style
  /etc/zsh/zshrc.d (and others want that feature, too, see
  https://bugs.debian.org/776663) and implemented in commit
  https://anonscm.debian.org/cgit/collab-maint/zsh.git/commit/?id=3e9c6a84
  in the branch zshrc.d, but there was opposition inside the team, so
  it has been never merged.

Frank Terbeck wrote:
> Disclaimer: Even though I am involved with grml's setup a great deal, I
>     never was a big fan of packaging it up for Debian. The reason for
>     that being mainly, that I am absolutely convinced that a vendor
>     should impose the least possible changes to a package as possible
>     and most certainly not impose a bunch of settings for every user on
>     a system.

That decision has not to be made by the vendor (i.e. us; neither in
the one nor in the other direction) but solely by the local admin. And
the vendor should IMHO help the local admin to implement that
decision, i.e. the package should ask the local admin (via debconf) if
the configuration should be globally enabled or not.

The default value is though discussable. As you probably guessed, I'm
in favour of enabling those configs by default if installed as I
expect that the majority of cases where it will be installed will be
on personal devices like laptops or desktops at home. But that's not a
strong opinion as I can easily live with any default value as long as
I can change it.

Frank: If making the default to not being enabled for all users by
default would void your opposition against such packages with plugins
or larger configurations, I'd be happy to implement it that way.

> That being said, I just realised that there is actually nothing at all
> missing for such a package. Zsh code like grml's setup doesn't belong to
> /etc anyway. We could probably distribute it somewhere in /usr/share/zsh.
> 
> Then users who want the setup can just
> 
>   source /usr/share/zsh/cfg/grml-zshrc
> 
> and be done. We could even package a byte-compiled version of the setup.

Yes, and we could add a symlink to it into /etc/zsh/zshrc.d/ upon
request by the local admin -- if that directory would exist. And that
kind of symlink definitely belongs to somewhere under /etc/.

> I am still firmly against anything that would enable the setup per
> default for everyone on a system.

As mentioned before, that's not our decision but the local admin's
decision. E.g. I would never enable it globally on the workstations at
work, but I would be annoyed if I couldn't enable it globally on my
own laptops which are not used by anyone else than myself. And of
course it would be enabled on live systems like grml itself, too.

BTW, IMHO the very same counts for the upcoming
zsh-syntax-highlighting package by Daniel Shahaf.

So I wonder if we should setup some management for these kind of
symlinks inside zsh-common. (But then again, those add-ons should
preferably also work with older zsh packages, so it should be an
optionally used framework.)

		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