Merely a tracker for changes that need to be done before EAPI=6 is enabled in games.eclass.
Due to no reply from games team to any of the bugs open, I have added a deprecation notice on top of the eclass and sent a patch to repoman.
What needs to happen to make games.eclass support EAPI 6? All I see here is a bug posting, a 6-day wait, and a deprecation notice. If there is discussion that occurred regarding this bug, please provide it via links so others can understand what has actually gone into this, if anything at all. Based on my digging, we have a few council decisions that actually impact things: * Games shouldn't be installed requiring a user to be in the 'games' group * Games that depend on separate/private statistics should be in the 'gamestat' group Reading the 20151213 council summary, I gathered that the only thing that needs changing in games.eclass is *not* defaulting to /usr/games/ or /usr/share/games, instead defaulting to /usr/share/ and/or /usr/bin. Has anyone read and addressed use cases that would be affected by this? A prime example is hosting all games on a specific filesystem type or media type (such as an SSD) which would benefit greatly from the speed increase. With all games in either /opt/ or /usr/games, this setup is possible. This doesn't include use cases where one machine is hosting game files for multiple other machines, in which case serving those over the network (at the exclusion of other files) may also be preferred. What do those against games.eclass have to offer to make those use cases remain? Given that no replacement to games.eclass has been suggested, how are the decisions related to the eclass to be taken seriously or acted upon in a constructive manner? Some developers wish to contribute to games and are tired of the petty arguing and non-actionable decisions. If a solution cannot be found, one will be made, and this isn't it, precisely because it deprecates functionality without replacing and/or enhancing it. To clarify, I'm not against progress, but I am against people changing things and breaking use cases without something to make those uses possible again. I don't care who the people are and don't have a dog in the fight. I want to be able to write game ebuilds that meet Gentoo standards *and* reach as many use cases as reasonable.
(In reply to Daniel Campbell from comment #2) > What needs to happen to make games.eclass support EAPI 6? All I see here is > a bug posting, a 6-day wait, and a deprecation notice. If there is > discussion that occurred regarding this bug, please provide it via links so > others can understand what has actually gone into this, if anything at all. This is a tracker. There are bugs linked. I'm not going to reply to any of the further spam. Please use appropriate discussion media instead of spamming tracker bugs.
(In reply to Daniel Campbell from comment #2) > What needs to happen to make games.eclass support EAPI 6? Games eclass is supposed to disappear as quickly as possible. This means in particular not adding any new ebuilds that use it.
(In reply to Daniel Campbell from comment #2) > Based on my digging, we have a few council decisions that actually impact > things: > > * Games shouldn't be installed requiring a user to be in the 'games' group > * Games that depend on separate/private statistics should be in the > 'gamestat' group > > Reading the 20151213 council summary, I gathered that the only thing that > needs changing in games.eclass is *not* defaulting to /usr/games/ or > /usr/share/games, instead defaulting to /usr/share/ and/or /usr/bin. Also don't create a games user and don't install an environment file. And after removal of all these from the eclass, there is neither a need for its wrapper functions any more, nor for prepgamesdirs(), nor for the postinst warning. Basically nothing of the current eclass will remain, which is no surprise because the council basically said that games should be treated as normal packages. > [...] > Given that no replacement to games.eclass has been suggested, how are the > decisions related to the eclass to be taken seriously or acted upon in a > constructive manner? I guess no replacement has been suggested because none is needed if games are normal packages. Also it is a little late for bringing these points up; this was on the agenda of several council meetings and there was enough time to speak up then.
Late or not, these points clearly weren't fully considered by the council. I don't see why the games team should be made to defend their work if they're the ones willing to maintain it all. It might all seem like pointless effort overhead to some people, but so what? Do what you want with your own packages, this is supposed to be a volunteer project.
What points weren't considered by the Council? I am nearly sure we have seen this discussion for years and the reaction from games team has usually being like "hiding" and ignoring on purpose all the discussions and resolutions. If there are any concrete points that you think weren't considered by the Council, then, feel free to clearly expose them and rise the topic (again) for the next Council meeting. But this kind of "boycott" way of preventing the games from being ported out of games.eclass is simply going to cause more important conflicts with no gain (apart of the QA issue of some games behaving in a complete different way than others)
(In reply to Tristan Heaven from comment #6) > Late or not, these points clearly weren't fully considered by the council. > As was suggested, by all means bring them up at a council meeting if they concern you. I wouldn't put any actions on hold in the meantime, unless a majority of council members agree to quickly put the previous decisions on hold. > I don't see why the games team should be made to defend their work if > they're the ones willing to maintain it all. It might all seem like > pointless effort overhead to some people, but so what? Do what you want with > your own packages, this is supposed to be a volunteer project. They don't have to defend anything, or indeed do anything. They're just prohibited from doing certain things, like porting this eclass to EAPI6, blocking commits to turn it into a NOOP, blocking commits to remove the use of the eclass, and so on. The people who are willing to do the work will do it. As you say, we're all volunteers, and the reality is that nobody can be forced to do anything. However, they can be prevented from interfering with those implementing agreed-upon decisions.
Two concrete things come to mind that the games.eclass file makes possible that, at best, is hazy without it. 1. Some games benefit more than others by being on faster media, or due to their size are better off on slower, more reliable media. games.eclass allows you to set an installation prefix for any ebuild that uses the eclass. From what I understand, this path mangling is one of the key reasons people don't like the eclass. I've not seen a suggestion to default its path to follow the rest of Gentoo, leaving it there for those who care to customize. If we did that, it'd actually nullify a lot of what people seem to have against it. There is package.env and EPREFIX, but they're poorly documented and none of the deprecation warnings offer them as ways to reclaim the functionality. Without a suggestion, deprecation just reeks of "we don't like this and don't care about those who use these packages." If that's the case, just say so. If you *do* care, then it's the responsible thing to give people a roadmap of migration. We issue news items for any big changes that users might need to intervene with; why should this be any different? 2. Games can be restricted to specific groups, to make use cases like game cafes or internet cafes possible, where people must ask to be in a given group or only trusted members may play games, etc. With games.eclass gone, how is that use case restored? Will people be forced to LDAP and other more-complex-than-necessary things? Ultimately it's use cases that suffer here, and those who are acting to get rid of games.eclass offer no legitimate migration plan or even a bandaid. We shouldn't accept that sort of behavior; otherwise I or someone else could enact whatever changes they want and because I or they'd be "doing the work", they'd stick. I'd be 100% behind this change if documentation were written that outlines a legitimate, workable way forward for those who depended on the behavior of the eclass. Responsibility falls to those who want to get rid of things to provide the migration. It's strange because normally we do a great job at helping users switch over to whatever's new, including use cases. Often the new thing allows for *more* use cases. But this situation is FUBAR and isn't being held to the same standard as other breaking changes.
What is the way to deal with games needing , usually, a highscores file writable for all the people? Thanks for the info :)
(In reply to Pacho Ramos from comment #10) > What is the way to deal with games needing , usually, a highscores file > writable for all the people? IIRC, the games group wasn't outlawed but I guess you need to create it in each ebuild now and it has to be called "games". I've never actually seen a game that has a highscores file like this but I guess there must be at least one somewhere.
The name was 'gamescores' IIRC.
I am getting more than one for sure while going with https://qa-reports.gentoo.org/output/eclass-usage/games.txt to port Please note that some upstreams tend to use "games" group for that (I think it's the first time I hear about gamescores naming). I don't care much about the name... but it was more for trying to choose the "most common" one to not need to keep patching many things in our side :)
Yes, upstreams used 'games' commonly for the purpose of scores. However, Gentoo has decided to abuse the same group name for a completely different purpose which means this group name was burnt and can't be used.
We have an explicit QA policy on this one: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games Games that need privileged access to shared high-score or game state files can be installed setgid (mode g+s or 2755). Group "gamestat" with gid 36 (but not the "games" group) should be used for them. The files for state/scores should then be created in /var/games or a subdirectory of it and have appropriate owner and permissions (root:gamestat, mode g+w).
Ah, thanks for the link One last question, why not use "games" group? I know that it has been used for all the games in the past, not only scores... but at some point all the tree will be migrated and, then, the group will be again free Also, maybe an eclass for creating the group and warning users that they need to be in that group would be interesting to ensure that the creation of the group is a bit more consistent between ebuilds :/
(In reply to Pacho Ramos from comment #16) > One last question, why not use "games" group? I know that it has been used > for all the games in the past, not only scores... but at some point all the > tree will be migrated and, then, the group will be again free The "games" group will continue to exist on users' systems (potentially for many years to come). > Also, maybe an eclass for creating the group and warning users that they > need to be in that group would be interesting to ensure that the creation of > the group is a bit more consistent between ebuilds :/ Users *must* *not* be members of the gamestat group.
(In reply to Ulrich Müller from comment #15) > We have an explicit QA policy on this one: > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games > > Games that need privileged access to shared high-score or game state files > can be installed setgid (mode g+s or 2755). Group "gamestat" with gid 36 > (but not the "games" group) should be used for them. The files for > state/scores should then be created in /var/games or a subdirectory of it > and have appropriate owner and permissions (root:gamestat, mode g+w). (In reply to Ulrich Müller from comment #17) > Users *must* *not* be members of the gamestat group. To be honest, setgid seems like a crappy solution. If the game writes any other files like config files then these will have a gamestat group too. Does it matter? Probably not, these are most likely very old and simple games. I'm a fan of ACLs but not everyone uses them. I guess you could put this stuff behind an acl flag if you care enough.
What should we do for games currently using games group for dedicated server things? Thanks
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f11830fc24e5f895c0c3686ca2e2d79fbfe44821 commit f11830fc24e5f895c0c3686ca2e2d79fbfe44821 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-04-09 20:27:37 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-04-09 20:27:49 +0000 profiles: add bug reference to games-misc/games-envd mask Closes: https://bugs.gentoo.org/574082 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 1 + 1 file changed, 1 insertion(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5ef4ea899b2fbdf66a46e2002ba8fd9be5ba1529 commit 5ef4ea899b2fbdf66a46e2002ba8fd9be5ba1529 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-09 10:59:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-09 10:59:26 +0000 games.eclass: remove last-rited eclass Closes: https://bugs.gentoo.org/574082 Signed-off-by: Sam James <sam@gentoo.org> eclass/games.eclass | 398 ---------------------------------------------------- 1 file changed, 398 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=034ee2d41fd57981f8d4b83f1f21dad5c8d1b5d9 commit 034ee2d41fd57981f8d4b83f1f21dad5c8d1b5d9 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-09 11:01:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-09 11:02:19 +0000 games-misc/games-envd: treeclean Closes: https://bugs.gentoo.org/574082 Signed-off-by: Sam James <sam@gentoo.org> games-misc/games-envd/games-envd-0.ebuild | 55 ------------------------------- games-misc/games-envd/metadata.xml | 8 ----- profiles/package.mask | 8 ----- 3 files changed, 71 deletions(-)
