PURPOSE: to standardize how Gentoo handles games PROBLEMS: (1) there is some complaints about the $PATH of Gentoo being too bloated (2) installation of games is completely dependant on the ebuild author and/or dev who commits the ebuild - permissions set with the group 'games' in mind, others do nothing - installing games to /opt, to /usr, to /usr/share/$PN, etc... POSSIBLE SOLUTIONS: we create an app-games eclass that uses variables/functions to control: - install destination for games - permissions on games/files
20:06 <@SpanKY> so we put libraries/binaries into /usr/games, pixmaps and such into /usr/share/games, and score files into /var/games (and we add an env.d entry for /var/games) what about the flags? "root:games o-rwx" would be nice imho. -phoen][x-
it's ok for me
I'm confused why this is necessary. How are games any different than any other application? I hate the bloated /usr/bin as much as the next guy, but that is the consisten place to put them. As for binary-only stuff like Quake and UT, I would be in favor of an /opt/bin directory to help with PATH problems.
we need standardization for games ... where the files go, who has access to them, so on and so forth ... we (bass, phoenix, and myself) consider 'games' to be of a different sort than any of the other packages because they are ... well ... games ... to fix the $PATH problem we have a seperate folder for binaries of games to fix the permissions issue, we have the ebuilds use variables/functions from the eclass most people dont want access to games while they are root, so we seperate out games from everything else and people 'opt in' for access to the games
Okay, in attempting to argue some more against this, I have talked myself into it. For the record, my biggest hangup is with putting stuff in /usr/games. Although it is not against the FHS (which explicitly mentions it as an optional "secondary hierarchy"), it opens the door for classifying all of our other categories under /usr as well (admin,arch,office,sci,etc.). Here is what changed my mind and I think the strongest argument for what you propose: according to the FHS, the whole reason for the / and /usr split is so that /usr/ can be shared read only in part or in full among like systems. By separating games into /usr/games, systems can choose whether or not to mount them at all, depending on the function of the machine. I think eclasses for all groups of applications are a good idea, in general, and we should look for other groups that would benefit from them.
phear the games.eclass
