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. |