On 08/22/2015 09:33 AM, Daniel Campbell (zlg) wrote: > On 08/21/2015 02:09 PM, James Le Cuirot wrote: >> On Fri, 21 Aug 2015 12:42:07 -0700 "Daniel Campbell (zlg)" >> <z...@gentoo.org> wrote: > >>>> Sure, we did drop this, but I don't really see this line of >>>> argument actually accomplishing anything productive. Creating >>>> a games team that fixes these issues would be productive. >>>> Letting others fix them is also productive. Nobody is opposed >>>> to having a games project - it just seems like nobody cares >>>> enough to actually make it happen. That's ok - we can still get >>>> things done. >>> >>> What would be required to revive the games project? One of the >>> reasons I became a dev was to help out the games team, and if >>> it's defunct, I want to see what's necessary to fix it. I'm still >>> a new dev (May 2015), but I wouldn't mind doing some dirty work >>> if it means we can put squabbles like this behind us and get >>> enough devs together to give game ebuilds the attention they >>> deserve. I don't have a lot of free time, but sitting here >>> discussing stuff isn't fixing anything, either... If I can spend >>> what little Gentoo time I have on fixing things, I'd be glad to. > >> At last, some positivity! As I said before, I would like to work on >> a few games too. I would certainly take up any Java-based ones and >> I have four of those in mind already. I've dabbled with ebuilds for >> many other games in the past, some already in the tree and some >> not, and some from source, some not. The Humble Bundle games are of >> particular interest to me. I'm obviously bogged with the more >> boring Java stuff for the foreseeable future though so as much as >> I'd like to, stepping up to be a lead would be unwise. > > I, too, have interest in Humble Bundle games since most of the games I > have and can test come from them. > > >> Do we actually need a team? Games come in all shapes and sizes so >> I think the assertion that they should be handled like any other >> application is somewhat valid. Many games are commercial so it's >> likely that certain games would only be handled by one or two team >> members anyway. The main thing I've been concerned about in the >> past is how to handle data. Should it be packaged separately? How >> do we handle the cdinstall flag these days when there are also >> multiple online sources like Humble Bundle and GOG? Do we just do >> whatever seems best for the game in question? I'd be happy to hold >> such discussions in a distro-wide fashion though. > > Despite games being "just another application", I think they differ > simply because they're a *different type* of application. Fonts and > icon-sets are similar to games in that they are mostly assets, and > they get the separate treatment they deserve. Games are an odd mix of > software and assets, so I think they deserve to be considered their > own type of software. They're also built in different ways than most > typical software is. >
Games differ in a lot of ways and they _require_ different policies. In some cases this also means more lax policies and in some cases more strict policies. An example is unbundling libraries. While unbundling libraries is often a good idea for regular well-maintained projects, it can often cause various problems for games: * games upstreams often modify 3rd party libraries * games upstreams often use libraries in very fishy ways, so you really need a very specific version * for proprietary games breakage often happens randomly at runtime * proprietary games may also break silently when library XY is bumped in the tree I've seen both opensource games and proprietary games that break when you unbundle libraries. One example is games-action/supertuxkart that was broken by a lot of packagers (including archlinux), because they didn't ask upstream if it was a good idea to unbundle Irrlicht. It wasn't. Another example is games-rpg/baldurs-gate-ee which has some weird graphical glitches when you unbundle libraries. The primary concern of gamers is that the game runs and that they can reasonably install it (see the games-roguelike/nethack bug which was unsolved for 8 years). Because of that, I provide a 'bundled-libs' USE flag for almost all proprietary games I package (e.g. those from GOG). So in case something breaks, the user can still opt-out of all this. Similarly, when upstream starts to heavily patch a library or when the system version of the library doesn't work half of the time for this game, then I simply drop back to the bundled version (probably creating a bug report or a note for that too), so that people can still enjoy it. And this is just one example where games-specific policies/guidelines are necessary. Another topic is ebuild cleanups which have to be handled differently for various reasons. > Great question on the 'cdinstall' flag. Games from Humble Bundle and > GOG are basically fetch-restricted and require the user to put the > relevant distfile in /usr/portage/distfiles to install. 'cdinstall' > could be applied only for games that the user wants to install via > optical media. With it off, it could default to the fetch restriction. > However, that could result in different checksums for the source. It > may not be feasible to go the cdinstall route forever. Honestly, I'd > need a concrete example and knowledge of the other releases to offer a > better-informed opinion. > Data ebuilds with cdinstall and optional gog sources are already available, see https://gitweb.gentoo.org/repo/gentoo.git/tree/games-fps/duke3d-data/duke3d-data-1.0-r2.ebuild https://gitweb.gentoo.org/repo/gentoo.git/tree/games-rpg/arx-fatalis-data/arx-fatalis-data-1.21-r2.ebuild There's not really a problem there. About data ebuilds... they make sense when at least some of these points are true: * data is very very big (you don't want extract 8GB just because you changed an engine USE flag) * upstream provides the engine and the data separately anyway * upstream sometimes bumps the data without bumping the engine or vice versa * we have a lot of data-specific USE flags (you don't want to recompile the whole engine just because you are trying different music-packs) * the data portion uses the cdinstall USE flag (you definitely want to decrease the number of times users have to look for their CD...) In some cases, we are forced to make data ebuilds anyway, e.g. when you have opensource engines for proprietary games. But there's no reason to split off -data ebuilds for every possible package. It's done if it makes sense and doesn't overcomplicate ebuild development and user-side configuration/installation.
