| 1 |
On 08/22/2015 05:25 PM, Rich Freeman wrote: |
| 2 |
> On Saturday, August 22, 2015, hasufell <hasufell@g.o> wrote: |
| 3 |
>> |
| 4 |
>> |
| 5 |
>> Games differ in a lot of ways and they _require_ different policies. In |
| 6 |
>> some cases this also means more lax policies and in some cases more |
| 7 |
>> strict policies. |
| 8 |
>> |
| 9 |
>> An example is unbundling libraries. While unbundling libraries is often |
| 10 |
>> a good idea for regular well-maintained projects, it can often cause |
| 11 |
>> various problems for games: |
| 12 |
>> * games upstreams often modify 3rd party libraries |
| 13 |
>> * games upstreams often use libraries in very fishy ways, so you really |
| 14 |
>> need a very specific version |
| 15 |
>> * for proprietary games breakage often happens randomly at runtime |
| 16 |
>> * proprietary games may also break silently when library XY is bumped in |
| 17 |
>> the tree |
| 18 |
> |
| 19 |
> |
| 20 |
> While I get what you're saying, none of the specific issues you listed |
| 21 |
> are actually unique to games, especially FOSS games. These sorts of |
| 22 |
> issues tend to happen with lots of desktop/multimedia-oriented |
| 23 |
> applications. I do agree that they hit games pretty hard though and |
| 24 |
> games maintainers should have a forum for discussing them. |
| 25 |
> |
| 26 |
|
| 27 |
Sure. You could say that there is no herd with special ebuilds. They all |
| 28 |
have build systems, bundled libraries and dependencies. But that was not |
| 29 |
the point. |
| 30 |
|
| 31 |
The point are the common pitfalls and the way they are handled. And that |
| 32 |
may differ greatly from other projects/herds, because you must keep in |
| 33 |
mind what your users expect and what is reasonable in that context. |
| 34 |
Tree-cleaning a vulnerable proprietary game is not reasonable. You just |
| 35 |
hardmask it. That is different for kernel packages. |
| 36 |
There are lots of other examples. |
| 37 |
|
| 38 |
Most herds (like python, ruby and whatnot) have their own understanding |
| 39 |
of consistency and quality that particularly applies to their domain. |
| 40 |
You can't make everything global. Some thing you should make global |
| 41 |
(e.g. if it is about dependency resolution, when to do revision bumps |
| 42 |
and so on) and others not. |
| 43 |
|
| 44 |
So my point stands. Games require their own set of policies (and ebuild |
| 45 |
writing guidelines). |
Archives