public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: hasufell <hasufell@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] games.eclass
Date: Sat, 22 Aug 2015 22:47:08 +0200	[thread overview]
Message-ID: <55D8DFCC.8070804@gentoo.org> (raw)
In-Reply-To: <CAGfcS_mbGyX+Ukphidro+shiQLjtZrwAHzD8j2+dc1Mm0fS3Qw@mail.gmail.com>

On 08/22/2015 05:25 PM, Rich Freeman wrote:
> On Saturday, August 22, 2015, hasufell <hasufell@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	other threads:[~2015-08-22 20:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-20 17:42 [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server Michał Górny
2015-08-20 18:03 ` hasufell
2015-08-20 19:32   ` James Le Cuirot
2015-08-20 20:17     ` hasufell
2015-08-20 19:56   ` Rich Freeman
2015-08-21  6:39     ` [gentoo-dev] " Duncan
2015-08-21 14:29   ` [gentoo-dev] " Ciaran McCreesh
2015-08-20 20:31 ` Alexander Berntsen
2015-08-20 21:19   ` [gentoo-dev] " Martin Vaeth
2015-08-20 21:33     ` hasufell
2015-08-20 22:06 ` [gentoo-dev] " Jason A. Donenfeld
2015-08-20 22:18   ` hasufell
2015-08-21  1:03     ` Rich Freeman
2015-08-21  3:11       ` Kent Fredric
2015-08-21  6:50     ` [gentoo-dev] games.eclass (was: Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server) Ulrich Mueller
2015-08-21 15:10       ` [gentoo-dev] games.eclass hasufell
2015-08-21 17:39         ` Rich Freeman
2015-08-21 18:17           ` hasufell
2015-08-21 18:44             ` Rich Freeman
2015-08-21 19:42           ` Daniel Campbell (zlg)
2015-08-21 21:09             ` James Le Cuirot
2015-08-22  7:33               ` Daniel Campbell (zlg)
2015-08-22  9:56                 ` Rich Freeman
2015-08-22 11:10                 ` hasufell
2015-08-22 14:32                   ` James Le Cuirot
2015-08-22 15:25                   ` Rich Freeman
2015-08-22 20:47                     ` hasufell [this message]
2015-08-22 23:48                       ` Rich Freeman
2015-08-22 18:01                   ` Daniel Campbell (zlg)
2015-08-22 21:16                     ` hasufell
2015-08-21  1:36 ` [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server Alexandre Rostovtsev
2015-08-21  7:16 ` Sergey Popov
2015-08-21  8:11   ` Kent Fredric
2015-08-21 10:58   ` Rich Freeman
2015-08-21 11:28     ` Alexander Berntsen
2015-08-21 12:04       ` Rich Freeman
2015-08-21 15:27         ` hasufell
2015-08-21 17:17           ` Rich Freeman
2015-08-21 18:29           ` [gentoo-dev] " Duncan
2015-08-21  8:31 ` [gentoo-dev] " Daniel Campbell (zlg)
2015-08-21 10:31   ` Rich Freeman
2015-08-21 11:01     ` Rich Freeman
2015-08-21 19:31     ` Daniel Campbell (zlg)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55D8DFCC.8070804@gentoo.org \
    --to=hasufell@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox