Re: [gentoo-dev] games.eclass

[Rich Freeman]

On Saturday, August 22, 2015, hasufell <hasufell@g.o> wrote:
>
>
> 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


While I get what you're saying, none of the specific issues you listed
are actually unique to games, especially FOSS games.  These sorts of
issues tend to happen with lots of desktop/multimedia-oriented
applications.  I do agree that they hit games pretty hard though and
games maintainers should have a forum for discussing them.

Where I think games tend to exacerbate this issue is that they're
often proprietary and non-free which makes detecting these issues
harder, and fixing them almost impossible for the library maintainers.
Also, they tend to not have equal FOSS substitutes.  A proprietary
word processor will tend to not have much interest in Gentoo because
there are so many decent FOSS alternatives.  Since games tend to be
more about the content then the engines, they tend to be expensive to
write FOSS replacements for, so people tend to use the proprietary
ones.

And that is why I think we have to be careful about just taking any
games issue and leaving it up to the games team.  I think they can
take the lead on raising these issues, and when nobody else has a
solution to their problems they should certainly have a bias for
action in solving them on their own.  However, when a problem does
have competing solutions across the tree or where there is value in
consistency we shouldn't just leave it up to the games team to do
whatever they want with the games.  Do we really want a world where
multimedia applications go in /usr/multimedia/bin, toolchain goes in
/usr/toolchain/bin, science goes in /usr/science/bin, and so on?  All
of those have projects, and all of them have unique concerns.  That
doesn't make all of their concerns unique.

--
Rich