Arch Linux User Repository

Ugh, it was a PITA to create this package. Please note that errors are silenced, so if you have any issues with zim, remove &>/dev/null from your /etc/zshrc - https://aur.archlinux.org/cgit/aur.git/tree/zshrc?h=zsh-zim-git&id=5a378e94d516c57d39629de545b78b0f020d86a4

I had to do it this way: $ZIM_HOME is only writable by root and zim constantly tries to update & recompile itself (=write to $ZIM_HOME), which results in permission errors when starting zsh as a normal user.

If you want to add/remove a module:

1. Add a respective zmodule in /etc/zsh/zimrc
2. Run as root: zimfw install && zsh

FWIW I agree with @bus. If I no longer have an interest in maintaining a package, I orphan it. This shows users that there is no one actively maintaining it, and may inspire others to adopt it. Hence the previous adoption drives. If we don't know which are unmaintained, then we can't adopt them. I also don't view it as my responsibility to protect against future "malicious intents". (Also, despite your earlier response, you aren't exactly responding to the "request" to update the package! And the fix is certainly actionable, at least in theory.)

Well, I could say either way, but the out-of-date flagging isn't really actionable. If you're not going to contribute, then I don't really see any point on discussing this meta-issue.

@ishitatsuyuki I suggest you read the flagging page: "Flagging this package should only be done if the sources moved or changes in the PKGBUILD are required because of recent upstream changes". The package does not build because upstream changed, it's literally out of date by definition.

Also, I don't think that's a correct interpretation of orphaning. It's very commonly done voluntarily when people have no desire to work on their packages, which you said you don't. You're thinking of assisted orphaning via requests, which is performed when the maintainer is not responding.

@bus Do not flag packages out-of-date for any reasons other than versions (which means that you should never flag a VCS package)!

I'm not going to let some random person take over this package without verifying they don't have malicious intents. Orphaning is only required when the maintainer (is intending to) no longer responds to any comments or requests.

Ah yes true. Thanks for the reply. I'll have a bit of a play and see if I can work out how to install it at a system level first, but yes, I might end up the same way.

I just switched to a user level install and I'm fine with that since I'm the only one using the computer anyway.

And using a package is not the only way to update, you could just set up a cron job or whatever.

Fair enough. TBH I thought about creating the stable zsh-zim package, but a brief look at upstream confused me. Out of interest, will you continue to use zsh-zim? And if so, will you just install it at a user-level?

EDIT: that's not my preference because I'd never remember to update it.

Since the upstream doesn't like zimfw getting packaged for global installation, and porting seems to be harder with the latest template changes, I'm going to stop maintaining this package. Contributions are still welcome.

This no longer builds for me.

==> Starting package()...
cp: cannot create regular file '/tmp/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/templates/zshrc': No such file or directory

It looks like the subdirectory templates is no longer present upstream.

Also, regarding the previous comments, there's now a stable release out: https://github.com/zimfw/zimfw/releases

Since zimfw does not have any releases at this point, I don't see any point in doing that.