Overview
@expeehaa Apologies for not looking at this more closely. I am in principle not opposed to this, I have just two points: - is /etc/ is really the place for this? This file looks like a script and /etc/ wouldn't be the right place for that - upstream is dead, do you really want to commit to maintaining this?
I agree that /etc/ is a bad place. Short explanation: rbenv has restrictions on where hooks can be placed (see https://github.com/rbenv/rbenv/wiki/Authoring-plugins#rbenv-hooks). Those are mainly the following 3 for system packages:
/usr/local/etc/rbenv.d/etc/rbenv.d/usr/lib/rbenv/hooks
/usr/local/etc does not seem to be the right place for system packages and the rpm builder in OBS doesn’t like /usr/lib for noarch packages (or at least it didn’t when I tested that). Therefore, I assume that /etc/ is the best solution right now. Maybe changing this in upstream rbenv would be good. /usr/share/rbenv/hooks/ looks better to me, but I don’t have much experience in filesystem hierarchy.
Also, I’m not sure if upstream is really dead. There have certainly been no updates in 8 years, but I’m actively using this rbenv plugin already and everything works. I assume its simply feature complete and rbenv updates don’t break things (and they are rare, only 5 releases since 2013). Since the plugin consists only of a 39 lines bash file, it doesn’t really need maintenance as long as rbenv keeps not breaking it. So I’ld be fine with maintaining it.
/usr/lib/ might actually be a slightly better fit, because we are trying to have system supplied scripts/configs in /usr/ and admin/user provided ones in /etc/. I agree that /usr/lib isn't perfect, but it's imho better than /etc/ and much better than /usr/local/ (which you must not use for packaging).
