Re: [gentoo-dev] games.eclass

[Daniel Campbell (zlg)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/22/2015 04:10 AM, hasufell wrote:
> 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)"
>>> <zlg@g.o> 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

Great points. Games often do rely on their bundled libraries, and
that's one of the biggest exceptions to the rule that I see *needs* to
apply to games; if bumping a dependent library breaks it, then we at
least need an option to make sure the game continues to work.

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

What happened with that bug? 8 years? That's insane!

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

Right, that flag is really handy in my experience. If you've worked on
Torchlight, Rochard, or Shatter, I'd like to thank you for your work
on them. 'bundled-libs' is a lifesaver with those games because they
*do* use modified libraries and it's the path of least pain to get
them to work. Sure, it's technically messy, but when the game comes
with libs already bundled on every other platform, it's best for us to
stay in line with that (if unbundling is too unstable). I liken it to
taking a statically linked application and dynamically linking it.
It's not trivial, and with many games being proprietary we don't
really have the means to fix things in an unbundled state. If it
works, great, things are a bit cleaner. But I think bundled libs are
here to stay for gaming.

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

What ebuild cleanups are we talking about, specifically?

>> 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/d
uke3d-data-1.0-r2.ebuild
>
>
https://gitweb.gentoo.org/repo/gentoo.git/tree/games-rpg/arx-fatalis-dat
a/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.
>

Thanks for the example and clarification on when the best time to
split ebuilds is. I never assumed it would apply to every engine/data
combo, but I knew there was a case for it somewhere.

Since you have some experience working on game ebuilds and are clearly
invested in seeing games maintain their quality, what do you want to
see happen to games on Gentoo? If we can gather a list of things we
want to do or fix (from games maintainers, users, and other devs),
maybe we can settle on actionable things and find a way forward.

Thanks again for your input, I appreciate it.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV2LkFAAoJEAEkDpRQOeFwfLIP/RmR4/lyQbkJ1ueHH/nxohBn
RKKaUVOxmY/cJiK/Yg7R59fny9Dz+nnNb+nQoVNJ9QGMqasKWFFKEU9dH8cHU6cN
q8SO0nDK9ppHF+AJoMsq+Oiyjta9JWV/55BgCyfXj8RAiCvPfiDneYL/T/V99U0R
4CxCQ8BCH38oZtM43pYi/yiSY703niGNU3e1+87kly1Mk47V8m4fwod/mXAXkJ28
Y0aXRNPTjSqaQCmMR4mcfuKvqoUrX7bMb9A3dNEsBER5Csm5zp0usaPz1uthDl1l
pnl3DCG7YOdCTqgHrJ5f945U905O97agqv30JNrZCr50psZryeRU3wVvnU0oa3Lm
9BEwlSxwdKOzGAY9O71SEI/lTCYNEXsGjBeWfJHtMytBNdEZaRCvebuQItGM8DVs
52CHvXYBfLSpreeRcnwgKJfVYlT+nJEslB1aJDCsTqb3rns6FZWDTlFbDSwU8sdi
wUeN0YlSPcbFI1YCYM5tIjuMACP708wvKXTaR56V4cT7JY0a9ZllZwhAFj34D84E
8dQ3jOlbXe4TSZ03cI4zLueLnNlO4OeUBBAQirDuYUI7mZ6uHXb4Xf0qngFDCpQ+
0JdX7E+qDFS0h1BUZO2yQHM1W6WqVL5aqUayu3nGzu75Qzw3Pc6A9LC+1m7u3j91
bQKDWmIdLSaZGF5Yk0ou
=o0rt
-----END PGP SIGNATURE-----