It seems that it is considered normal to drop prefix changes and keywords without notice, because games.eclass isn't EAPI=3 ready. This bug serves the purpose of reminding me to port games.eclass to EAPI=3, and to ask the games people to approve it once it's ready. I guess it's too late to try and list ebuilds that have gone lost this way, which is a shame in both ways.
Created attachment 246621 [details, diff] eapi=3 and prefix patch for games.eclass @games: please review the attached patch. It makes the games.eclass ready for Prefix and EAPI=3.
@games: please give some comment
The parts that start with use prefix || look wrong to me. games_set_prefix_vars seems unnecessary since it should be enough for it to be inline in games_pkg_setup
(In reply to comment #3) > The parts that start with use prefix || look wrong to me. We can't chown or chmod as the non-root user so if prefix is in USE then don't try to chown/chmod (and fail because the user can't do it). > > games_set_prefix_vars seems unnecessary since it should be enough for it to be > inline in games_pkg_setup >
Why change D to ED then?
Created attachment 260877 [details, diff] updated eapi=3 patch for games.eclass games_set_prefix_vars is now an integral part of games_pkg_setup
why not change GAMES_USER and such to valid accounts in prefix profiles then ? as for the EPREFIX stuff, instead of updating every reference, how about putting it into the base definition ? then no call sites need to be updated. -export GAMES_PREFIX=${GAMES_PREFIX:-/usr/games} +export GAMES_PREFIX=${GAMES_PREFIX:-${EPREFIX}/usr/games}
(In reply to comment #7) > why not change GAMES_USER and such to valid accounts in prefix profiles then ? You don't have control over them. The only user you know is the user you run as. > as for the EPREFIX stuff, instead of updating every reference, how about > putting it into the base definition ? then no call sites need to be updated. > > -export GAMES_PREFIX=${GAMES_PREFIX:-/usr/games} > +export GAMES_PREFIX=${GAMES_PREFIX:-${EPREFIX}/usr/games} This is only possible when we assume the caller sets GAMES_PREFIX including $EPREFIX, and also that GAMES_PREFIX isn't used with helpers. It seems the eclass uses it with into. Easy to change that, both ways are possible options to me.
but you can easily do: GAMES_USER=`whoami` as for GAMES_PREFIX & friends, if a user changes it to a location where they dont have control, that's their problem.
In tree games.eclass supports EAPI=3. Is there any reason to keep this bug open? Also looks like it's time to add support for EAPI=4 :)
It would be nice to have eapi4 :) Without any other desired changes adding 4 to known eapis is working enough.
(In reply to comment #11) > Without any other desired changes adding 4 to known eapis is working enough. Ditto, please bump.
Created attachment 297227 [details, diff] games.eclass-eapi4.patch Patch to support EAPI4 by making more things automatically die.
Would be nice to have EAPI 4 support. I need to use REQUIRED_USE, but right now I'm tied down to overriding pkg_setup() and use confutils.eclass.
Any activity on this bug?
Hey, guys! Can I help with porting of eclass to EAPI4? We're all need EAPI4-compat games.eclass
(In reply to comment #16) > Hey, guys! Can I help with porting of eclass to EAPI4? > We're all need EAPI4-compat games.eclass Hack existing games ebuilds locally to fool the eclass: EAPI=4 EAPI=3 inherit games <ebuild shit>... and add EAPI=4 specific stuff like REQUIRED_USE etc pp and see how they behave. Report eclass-specific bugs here if you find some (or open a new one and make it block this bug). There are some common errors you might encounter like "The source directory '${S}' doesn't exist", cause EAPI=4 does not default to "${WORKDIR}" if "${WORKDIR}/${P}" is not found. That's ebuild-specific and expected and not worth a bug.
(In reply to comment #17) > Hack existing games ebuilds locally to fool the eclass: > > EAPI=4 > > EAPI=3 inherit games Please don't do this, because the resulting behaviour would be completely undefined. Ebuilds must not assign EAPI more than once.
(In reply to comment #18) > (In reply to comment #17) > > Hack existing games ebuilds locally to fool the eclass: > > > > EAPI=4 > > > > EAPI=3 inherit games > > Please don't do this, because the resulting behaviour would be completely > undefined. Ebuilds must not assign EAPI more than once. Right, the second-level inherited eclasses could cause unexpected behavior. Seems it has been bumped already anyway: slyfox 12/05/30 06:35:44 Modified: ChangeLog games.eclass Log: Allow EAPI=4.
ok, I'v ported a few ebuilds things to look for: - ${S} does not default to ${WORKDIR} if ${WORKDIR}/${P} is not found - remove "|| die" from helper functions (not from shell commands) - remove prepalldocs - check-reqs.eclass now exports pkg_pretend, so better put things like CHECKREQS_DISK_BUILD="3G" in global scope, otherwise it will say: check-reqs_prepare: check-reqs eclass called but not actualy used! - check for fancy checks in pkg_setup or usex lines that work around missing REQUIRED_USE - RDEPEND="${DEPEND}" is not assigned when RDEPEND is unset - consider using function "default" also in src_install instead of "emake ... install"
Current EAPI=4 with games.eclass fails with errors * ERROR: games-fps/lonesurvivor-1.11d_p1 failed (install phase): * fowners failed * ERROR: games-fps/lonesurvivor-1.11d_p1 failed (install phase): * fperms failed
Created attachment 314819 [details, diff] games.eclass-fowners.patch (In reply to comment #21) > Current EAPI=4 with games.eclass fails with errors > > * ERROR: games-fps/lonesurvivor-1.11d_p1 failed (install phase): > * fowners failed > * ERROR: games-fps/lonesurvivor-1.11d_p1 failed (install phase): > * fperms failed That is related to some unconditional fperms/fowners calls that do not check if the directories exist. Since EAPI=4 all helpers die unless you set "nonfatal" before them and because the directories do not exist we get this error. Attached patch to eclass should fix that. Can you confirm?
With this patch fperms/fowner works correctly. But please, double check commits to eclass. And where in games.eclass DOCUMENTATION?
(In reply to comment #23) > With this patch fperms/fowner works correctly. > > But please, double check commits to eclass. The switch to EAPI=4 was expected to have side effects, but it did not break ANY existing ebuild, cause all of them where still on EAPI=3 or lower. The user is completely unaffected of this migration, only developers and ebuild writers may encounter bugs and issues. If people just bump/publish their ebuilds to EAPI=4 without testing then it's their own fault. > And where in games.eclass DOCUMENTATION? Please open a new documentation bug for that.
