[Pkg-zsh-devel] RFS: oh-my-zsh/0~20140211-1 [ITP]

[Axel Beckert]

Hi Jerome,

Jerome Charaoui wrote:
> Am I to understand that oh-my-zsh was previously packaged for Debian,
> and was removed?

No.

> Is oh-my-zsh of good enough quality to be included in Debian?

That's what some of us think, yes.

> Would to care to share some of those bugs you refer to?

As I'm the newest zsh user in the team, I think I remember only one or
two cases in the BTS, but I don't remember any details as we usually
close them if they can't be reproduced without oh-my-zsh. But maybe
some of the other team members do.

Another (not really traceable) place where these issue are said to
regularily surface is the #zsh channel on IRC (Freenode network). But
I'm not active there either. If you are on IRC anyway, maybe lurk
around there for a while and see if get aware of oh-my-zsh issues.

> I may be overlooking serious issues which might make me change my
> mind about oh-my-zsh.

>From what I've heard it seems not a single issue but more lacking
quality.

One thing I noticed (while reviewing your patches) is that Oh My Zsh
seems to use the environment variable $ZSH to check if it is installed
or not. Which is IMHO either arrogant or incompentent. (But that's not
your problem, you patched away that check anyways. :-)

> Similarly, perhaps it has evolved positively since the team last
> gave it a shot?

That may be possible.

But the fact that there don't seem to be any releases makes me doubt a
little bit.

I don't say that this is a no go in general. It may work out, and it
works for me for two of my packages(*), but you need to get a feeling
for when upstream is broken and when it's stable. In my case lots of
commits recently usually mean to wait with the next package. No
commits for weeks usually mean that there are no important current
issues.

(*) conkeror's "releases" are milestones, i.e. more buggy than
    non-releases. :-) And screen hasn't had a release for many years,
    but tons of bug-fixes and new features in the current development
    version in git.

> > Most issues I found so far seem to be not packaging related:
> > 
> > "oh-my-zsh-config --install" does not check if I have already zsh as
> > login shell and calls chsh unconditionally
> > 
> > Likewise "oh-my-zsh-config --uninstall" wants to change my login shell
> > to bash despite it never was bash. It should e.g. honour if the user
> > had zsh or tcsh previously.
> 
> The install.sh and uninstall.sh scripts provided in oh-my-zsh are really
> not pretty. I think my preffered solution would be to simply *not* ship
> these scripts, and instead further document usage of oh-my-zsh in
> README.Debian. Would this be acceptable?

Sure.

It's a good question, though. Using README.Debian is probably less
error-prone, but the idea of scripts is neat for those who don't want
to fiddle themselves with config files, especially because I suspect
quite some of these people in the (potential) oh-my-zsh user base and
hence part of what people expect from oh-my-zsh. Difficult to say
what's the "better" way.

Maybe install the scripts as documentation or examples for now and
when you think, they're mature enough, put them back into /usr/bin/.

Those scripts seem not to be patched heavily, so it seems as if that
chsh feature is from upstream. If I would be you, I'd forward that
issue to upstream, maybe they fix it for you. :-)

> I haven't followed it long enough to know how upstream dev rolls. I was
> thinking of simply reviewing the commitlog every few weeks, and update
> the package when it seems right (eg, when there are a bunch of bug
> fixes).

See above for my experience with upstream projects without real
releases.

One more comment about the patches as I had a closer look for checking
what's from the original install/uninstall scripts and what's patched:

>From 03-Strip-download-removal-of-omz-in-home-directory.patch:

-cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
+cp /usr/share/doc/oh-my-zsh/examples/zshrc.zsh-template ~/.zshrc

You use a file under /usr/share/doc/ for functionality. That violates
Policy §12.3: "Packages must not require the existence of any files in
/usr/share/doc/ in order to function. Any files that are referenced by
programs but are also useful as stand alone documentation should be
installed under /usr/share/package/ with symbolic links from
/usr/share/doc/package." See
https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 for the
full text.

Background is that the system administrator should be able to delete
files in /usr/share/doc/ without causing any programs to break.
Actually there are some Debian derivatives who do that, Maemo for
example but IIRC also one or more of the Emdebian flavours.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5