Arch Linux User Repository

I've just tried removing ruby, none of my plugins broke. Here's a patch file for changing the optdepends: (no new pkgrel needed as it changes nothing)

--- a/PKGBUILD
+++ b/PKGBUILD
@@ -14,11 +14,9 @@
 license=('MIT')
 depends=('zsh')
 makedepends=('git')
-optdepends=('ruby: for some plugin functionality'
-            'python: for some plugin functionality'
-            'zsh-theme-powerlevel10k: great theme'
-            'bullet-train-oh-my-zsh-theme-git: better powerline theme'
-            'git: most themes use git (highly recommended but still optional)')
+optdepends=('python: for some plugin functionality'
+            'zsh-theme-powerlevel10k-bin-git: great theme'
+            'git: most updates are distributed through git')
 install=${pkgname}.install
 source=("${pkgname}::git+https://github.com/ohmyzsh/ohmyzsh.git"
         '0001-zshrc.patch')

Yes I'm on aur-general so I'll follow the thread if anything pops up.

By give it a shot I meant to locally remove ruby from dependencies and see if anything breaks, but as I said I think it is informative only. Same goes for powerline - migrate it to powerlevel10k and share a patch with us.

Hmm, that makes more sense. What do you mean by "feel free to give it a shot", though? Only the package's maintainer has access to changing the files.

Rein Fernhout's is the only reply I've gotten from aur-general so far.

Also, doesn’t getting stuff from the AUR already require git? We don’t need to include that either, do we

You cannot assume someone has git. You might want to build packages on a different system an distribute them.

As for the other (ruby, python) idk. I don't use powerline nor ruby, feel free to give it a shot. I think it is informative - "ruby as optdepend: hey it looks like it's got some tasty ruby plugins".

Let's see what "[aur-general]" has to say about this issue, thanks for posting there. As I said this package shall follow the will of the people using it if only it's valid.

Just one thing I wanted to clarify. Using upstream's install.sh in /bin would be a disaster as bad as curl|bash. I meant to put there the same stuff you want to put in the post-install script, but it could actually allow copying the template zshrc.

I think a message in the postinstall script is the right way to go here, as many other packages do.

However I could've also missed that message, as it is a bit overshadowed by the optional dependencies displayed right after. Why not also echo a couple of newlines and maybe some ##### bars to draw the attention?

—Rein Fernhout

Speaking of which, shouldn’t the powerline themes be replaced with the actually maintained powerlevel10k? And I don’t think ruby should be included, anything that uses Ruby can include it as their own dependent. Also, doesn’t getting stuff from the AUR already require git? We don’t need to include that either, do we?

Thanks for responding!

I would give more weight to your arguments regarding the postinstall message if there wasn't one already. The current one is VERY suspicious, and I suggest to either remove it or clarify it. postinstall is also where post-install echos go (I've asked that on aur-general before), and many packages have used this place for additional instructions.

I get the impression that install.sh is the official install script. I don't think we should symlink that to oh-my-zsh-something. At most, it should echo the instructions.

Plus, I think this is a worse solution than simply putting a message in the postinstall on both merits and practicality. No matter how much people try it, there will be less people who try to tab-complete than those who read the postinstall messages, and nowhere in "know your system" do I see "blindly try tab-completions"; not to mention this package's name is oh-my-zsh-git, not ohmyzsh-git. Yes, ohmyzsh is the official name, but I don't expect users to know that. We cannot rely on users having hyphen completions enabled.

Anyways, I've send a copy of this to aur-general with you two as Cc's. Cheers!

@starquake thank you for sharing your opinion. It matches mine. "expecting users to know" is a catchword. One could think that pacman unites us, but really isn't it the wiki that binds the community together? Let's do our best to introduce a section to zsh's wiki page.

I would be against including a post install script. This looks to me to be against the Arch Linux principles. Users are expected to know their way on a Linux system.

In the PKGBUILD you can see it is installed to /usr/share/oh-my-zsh.

You can find an example config there. I would say that's enough for a user to get going.

Alternatively a mention of this could be included in the Arch Wiki for ZSH.

Hello. Thank you all guys for all your input.

I personally think that post install message won't help much and isn't the way to fix the issue - for example for those that install packages with automation tools (such as Ansible). My opinion might be wrong, the wiki lacks instructions on how the install script should be used.

Please consider posting a message to a mailing list such as aur-general to get help from TUs or someone else. I might do that myself, but I think it's more reasonable that it is posted by a person that is actually for the change. (I'm looking at you @aliu (thanks again)).

Another solution would be to convince upstream to provide instructions (and possibly tools) to easily install oh-my-zsh. It is more likely for me personally to ignore pacman's output and try to tab-complete a command right after installing a package. It could be ohmyzsh-install, which would inform on how to use the package and maybe even ask the user about his current zshrc, backup it, replace or modify. System packages are not an official way of installing ohmyzsh, and that should be changed (imho) - because curl | bash is simply wrong. Please consider working with upstream first.

I won't refuse to add the post install script if the solution is deemed valid and is the voice of the people.

Please do not flag the package out of date. I am confident that all flags were not valid and I will unflag every time.

The reason people flag this is that the postinstall message isn't clear enough to tell us how to activate the package, which results in confusion "the package no work!". The maintainer hasn't responded to us in two months either... I'll write an email to them, and if they don't respond, do an orphan request.

Disclaimer: I'm not a Package Maintainer; I don't know how to unflag things.