This eclass is required by the new GGZ 0.0.10 ebuilds that install game clients so that they are installed correctly into /etc/ggz/ggz.modules Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 49940 [details] GGZ eclass
So why exactly does the ebuild need to die if etc-update hasn't been run? That is a *very* bad idea as it'll break world updates. Do the ggz.modules files ever need to be updated by the user? If not, we could install them somewhere that isn't under CONFIG_PROTECT, assuming they don't stomp all over each other, that is.
Each time a new set of games is installed ggz.modules is updated. If etc-update is not run then when a second set of games is installed the first set would effectively be removed. I agree, it's totally nasty but was the way I could see it would work. Version 0.0.12 comes out at the end of the month and removes the need for ggz.eclass so I'd wait for that.
Heh... figures... I was about to go and clean up about 10 GGZ bugs... hehe... I'll wait, sounds like a better solution anyway. My idea was to find another location to store the ggz.modules file than /etc, since it isn't "user editable" configuration data, but rather installation-related metadata. If the newer versions resolve the issue better, I'll definitely wait for them instead.
Well, 0.0.12 has been out for a while, do I'm marking this as WONTFIX.
