On 08/22/2015 05:25 PM, Rich Freeman wrote:
> On Saturday, August 22, 2015, hasufell <hasuf...@gentoo.org> 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.
> 
Sure. You could say that there is no herd with special ebuilds. They all
have build systems, bundled libraries and dependencies. But that was not
the point.

The point are the common pitfalls and the way they are handled. And that
may differ greatly from other projects/herds, because you must keep in
mind what your users expect and what is reasonable in that context.
Tree-cleaning a vulnerable proprietary game is not reasonable. You just
hardmask it. That is different for kernel packages.
There are lots of other examples.

Most herds (like python, ruby and whatnot) have their own understanding
of consistency and quality that particularly applies to their domain.
You can't make everything global. Some thing you should make global
(e.g. if it is about dependency resolution, when to do revision bumps
and so on) and others not.

So my point stands. Games require their own set of policies (and ebuild
writing guidelines).

Reply via email to