Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] games.eclass
Date: Sat, 22 Aug 2015 11:11:08
Message-Id: 55D858BE.90902@gentoo.org
In Reply to: Re: [gentoo-dev] games.eclass by "Daniel Campbell (zlg)"
1 On 08/22/2015 09:33 AM, Daniel Campbell (zlg) wrote:
2 > On 08/21/2015 02:09 PM, James Le Cuirot wrote:
3 >> On Fri, 21 Aug 2015 12:42:07 -0700 "Daniel Campbell (zlg)"
4 >> <zlg@g.o> wrote:
5 >
6 >>>> Sure, we did drop this, but I don't really see this line of
7 >>>> argument actually accomplishing anything productive. Creating
8 >>>> a games team that fixes these issues would be productive.
9 >>>> Letting others fix them is also productive. Nobody is opposed
10 >>>> to having a games project - it just seems like nobody cares
11 >>>> enough to actually make it happen. That's ok - we can still get
12 >>>> things done.
13 >>>
14 >>> What would be required to revive the games project? One of the
15 >>> reasons I became a dev was to help out the games team, and if
16 >>> it's defunct, I want to see what's necessary to fix it. I'm still
17 >>> a new dev (May 2015), but I wouldn't mind doing some dirty work
18 >>> if it means we can put squabbles like this behind us and get
19 >>> enough devs together to give game ebuilds the attention they
20 >>> deserve. I don't have a lot of free time, but sitting here
21 >>> discussing stuff isn't fixing anything, either... If I can spend
22 >>> what little Gentoo time I have on fixing things, I'd be glad to.
23 >
24 >> At last, some positivity! As I said before, I would like to work on
25 >> a few games too. I would certainly take up any Java-based ones and
26 >> I have four of those in mind already. I've dabbled with ebuilds for
27 >> many other games in the past, some already in the tree and some
28 >> not, and some from source, some not. The Humble Bundle games are of
29 >> particular interest to me. I'm obviously bogged with the more
30 >> boring Java stuff for the foreseeable future though so as much as
31 >> I'd like to, stepping up to be a lead would be unwise.
32 >
33 > I, too, have interest in Humble Bundle games since most of the games I
34 > have and can test come from them.
35 >
36 >
37 >> Do we actually need a team? Games come in all shapes and sizes so
38 >> I think the assertion that they should be handled like any other
39 >> application is somewhat valid. Many games are commercial so it's
40 >> likely that certain games would only be handled by one or two team
41 >> members anyway. The main thing I've been concerned about in the
42 >> past is how to handle data. Should it be packaged separately? How
43 >> do we handle the cdinstall flag these days when there are also
44 >> multiple online sources like Humble Bundle and GOG? Do we just do
45 >> whatever seems best for the game in question? I'd be happy to hold
46 >> such discussions in a distro-wide fashion though.
47 >
48 > Despite games being "just another application", I think they differ
49 > simply because they're a *different type* of application. Fonts and
50 > icon-sets are similar to games in that they are mostly assets, and
51 > they get the separate treatment they deserve. Games are an odd mix of
52 > software and assets, so I think they deserve to be considered their
53 > own type of software. They're also built in different ways than most
54 > typical software is.
55 >
56
57 Games differ in a lot of ways and they _require_ different policies. In
58 some cases this also means more lax policies and in some cases more
59 strict policies.
60
61 An example is unbundling libraries. While unbundling libraries is often
62 a good idea for regular well-maintained projects, it can often cause
63 various problems for games:
64 * games upstreams often modify 3rd party libraries
65 * games upstreams often use libraries in very fishy ways, so you really
66 need a very specific version
67 * for proprietary games breakage often happens randomly at runtime
68 * proprietary games may also break silently when library XY is bumped in
69 the tree
70
71 I've seen both opensource games and proprietary games that break when
72 you unbundle libraries. One example is games-action/supertuxkart that
73 was broken by a lot of packagers (including archlinux), because they
74 didn't ask upstream if it was a good idea to unbundle Irrlicht. It wasn't.
75 Another example is games-rpg/baldurs-gate-ee which has some weird
76 graphical glitches when you unbundle libraries.
77
78 The primary concern of gamers is that the game runs and that they can
79 reasonably install it (see the games-roguelike/nethack bug which was
80 unsolved for 8 years).
81
82 Because of that, I provide a 'bundled-libs' USE flag for almost all
83 proprietary games I package (e.g. those from GOG). So in case something
84 breaks, the user can still opt-out of all this.
85
86 Similarly, when upstream starts to heavily patch a library or when the
87 system version of the library doesn't work half of the time for this
88 game, then I simply drop back to the bundled version (probably creating
89 a bug report or a note for that too), so that people can still enjoy it.
90
91 And this is just one example where games-specific policies/guidelines
92 are necessary. Another topic is ebuild cleanups which have to be handled
93 differently for various reasons.
94
95 > Great question on the 'cdinstall' flag. Games from Humble Bundle and
96 > GOG are basically fetch-restricted and require the user to put the
97 > relevant distfile in /usr/portage/distfiles to install. 'cdinstall'
98 > could be applied only for games that the user wants to install via
99 > optical media. With it off, it could default to the fetch restriction.
100 > However, that could result in different checksums for the source. It
101 > may not be feasible to go the cdinstall route forever. Honestly, I'd
102 > need a concrete example and knowledge of the other releases to offer a
103 > better-informed opinion.
104 >
105
106 Data ebuilds with cdinstall and optional gog sources are already
107 available, see
108 https://gitweb.gentoo.org/repo/gentoo.git/tree/games-fps/duke3d-data/duke3d-data-1.0-r2.ebuild
109 https://gitweb.gentoo.org/repo/gentoo.git/tree/games-rpg/arx-fatalis-data/arx-fatalis-data-1.21-r2.ebuild
110
111 There's not really a problem there.
112
113 About data ebuilds... they make sense when at least some of these points
114 are true:
115 * data is very very big (you don't want extract 8GB just because you
116 changed an engine USE flag)
117 * upstream provides the engine and the data separately anyway
118 * upstream sometimes bumps the data without bumping the engine or vice versa
119 * we have a lot of data-specific USE flags (you don't want to recompile
120 the whole engine just because you are trying different music-packs)
121 * the data portion uses the cdinstall USE flag (you definitely want to
122 decrease the number of times users have to look for their CD...)
123
124 In some cases, we are forced to make data ebuilds anyway, e.g. when you
125 have opensource engines for proprietary games.
126
127 But there's no reason to split off -data ebuilds for every possible
128 package. It's done if it makes sense and doesn't overcomplicate ebuild
129 development and user-side configuration/installation.

Replies

Subject Author
Re: [gentoo-dev] games.eclass James Le Cuirot <chewi@g.o>
Re: [gentoo-dev] games.eclass Rich Freeman <rich0@g.o>
Re: [gentoo-dev] games.eclass "Daniel Campbell (zlg)" <zlg@g.o>