Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 574082 (games.eclass) - [TRACKER] games.eclass deprecation
Summary: [TRACKER] games.eclass deprecation
Status: IN_PROGRESS
Alias: games.eclass
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Games
URL: https://wiki.gentoo.org/wiki/Project:...
Whiteboard:
Keywords: Tracker
Depends on: 149101 155538 436140 492498 494208 496472 566498 574080 606736 613696 626568 646748 667700 160305 181372 254510 481708 515660 548926 567036 582326 587382 608806 612322 617908 630576 634116 640550 640572 640580 640582 640584 642996 648890 648892 651146 653180 653182 653812 653998 654282 654286 654290 654294 654302 654336 654348 654352 654480 654482 654492 654510 654516 654520 654552 654554 654564 654650 654654 654658 659334
Blocks: ebuild-prep metatracker
  Show dependency tree
 
Reported: 2016-02-07 11:14 UTC by Michał Górny
Modified: 2019-04-11 15:49 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-02-07 11:14:32 UTC
Merely a tracker for changes that need to be done before EAPI=6 is enabled in games.eclass.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-02-13 16:40:42 UTC
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.
Comment 2 zlg (RETIRED) gentoo-dev 2016-06-20 08:17:02 UTC
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.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-21 15:46:47 UTC
(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.
Comment 4 Andreas K. Hüttel gentoo-dev 2016-06-21 16:26:25 UTC
(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.
Comment 5 Ulrich Müller gentoo-dev 2016-06-21 16:36:53 UTC
(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.
Comment 6 Tristan Heaven (RETIRED) gentoo-dev 2016-06-21 21:45:44 UTC
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.
Comment 7 Pacho Ramos gentoo-dev 2016-06-29 11:00:53 UTC
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)
Comment 8 Richard Freeman gentoo-dev 2016-06-29 11:20:55 UTC
(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.
Comment 9 zlg (RETIRED) gentoo-dev 2016-06-29 22:39:59 UTC
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.
Comment 10 Pacho Ramos gentoo-dev 2018-04-23 18:03:58 UTC
What is the way to deal with games needing , usually, a highscores file writable for all the people? 

Thanks for the info :)
Comment 11 James Le Cuirot gentoo-dev 2018-04-23 19:21:35 UTC
(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.
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-04-23 19:23:25 UTC
The name was 'gamescores' IIRC.
Comment 13 Pacho Ramos gentoo-dev 2018-04-23 19:25:22 UTC
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 :)
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-04-23 19:43:27 UTC
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.
Comment 15 Ulrich Müller gentoo-dev 2018-04-23 19:52:40 UTC
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).
Comment 16 Pacho Ramos gentoo-dev 2018-04-23 20:23:07 UTC
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 :/
Comment 17 Ulrich Müller gentoo-dev 2018-04-23 20:36:20 UTC
(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.
Comment 18 James Le Cuirot gentoo-dev 2018-04-23 21:11:16 UTC
(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.
Comment 19 Pacho Ramos gentoo-dev 2018-05-02 10:04:09 UTC
What should we do for games currently using games group for dedicated server things? 

Thanks