[gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Hi,

Right now, a number of game packages are using USE=dedicated to control
'installing a dedicated game server only'. Aside to that, some game
packages also have USE=server that controls building the server itself.
Non-game package use USE=client and USE=server.

In order to improve uniformity of USE flags across different packages,
the QA team would like to deprecate USE=dedicated and use USE=client
and USE=server as appropriate.

The problems I see with USE=dedicated are:

- it is game-specific. The term 'dedicated server' is not used amongst
  other server/client model packages.

- It uses negative logic. Instead of enabling something, it disables
  client. Pretty much 'dedicated' == 'noclient'. Negative logic is
  confusing.

- In packages having USE=server as well, it can lead to really absurd
  combinations, like what does 'USE=dedicated -server' mean? Will it
  build no executables at all? If we add REQUIRED_USE='dedicated?
  ( server )', this gets quite unfriendly.

As an alternative, we would use USE=client and USE=server along with
proper IUSE defaults to control client & server builds appropriately.
Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
is rather clear.

Does anyone see any real problems with that?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[hasufell]

On 08/20/2015 07:42 PM, Michał Górny wrote:
> Hi,
> 
> Right now, a number of game packages are using USE=dedicated to control
> 'installing a dedicated game server only'. Aside to that, some game
> packages also have USE=server that controls building the server itself.
> Non-game package use USE=client and USE=server.
> 
> In order to improve uniformity of USE flags across different packages,
> the QA team would like to deprecate USE=dedicated and use USE=client
> and USE=server as appropriate.
> 
> The problems I see with USE=dedicated are:
> 
> - it is game-specific. The term 'dedicated server' is not used amongst
>   other server/client model packages.
> 
> - It uses negative logic. Instead of enabling something, it disables
>   client. Pretty much 'dedicated' == 'noclient'. Negative logic is
>   confusing.
> 
> - In packages having USE=server as well, it can lead to really absurd
>   combinations, like what does 'USE=dedicated -server' mean? Will it
>   build no executables at all? If we add REQUIRED_USE='dedicated?
>   ( server )', this gets quite unfriendly.
> 
> As an alternative, we would use USE=client and USE=server along with
> proper IUSE defaults to control client & server builds appropriately.
> Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
> is rather clear.
> 
> Does anyone see any real problems with that?
> 

That increases the burden of managing configuration and further abuses
REQUIRED_USE where it wasn't meant to be used in the first place.

USE="dedicated" has worked fine for games users and no one has ever
complained. In fact, it is a _very_ convenient USE flag, which means "no
manual fiddling, this will be dedicated for sure".

-1

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Thu, 20 Aug 2015 20:03:26 +0200
hasufell <hasufell@gentoo.org> wrote:

> > As an alternative, we would use USE=client and USE=server along with
> > proper IUSE defaults to control client & server builds
> > appropriately. Both flags use positive logic, and REQUIRED_USE='||
> > ( client server )' is rather clear.
> 
> That increases the burden of managing configuration and further abuses
> REQUIRED_USE where it wasn't meant to be used in the first place.
> 
> USE="dedicated" has worked fine for games users and no one has ever
> complained. In fact, it is a _very_ convenient USE flag, which means
> "no manual fiddling, this will be dedicated for sure".

I'm don't feel very strongly about it but as someone who is considering
working on more games in the future, I like what mgorny has suggested.
I don't think the micro-managing argument flies so well here because
these flags are much less common than flags like qt. client and server
would probably be enabled by default in most cases and I doubt there
are any games where you can't have both. If there were a conflict then
you would want to make a concious decision as it's more significant
than choosing a GUI toolkit.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Thu, Aug 20, 2015 at 2:03 PM, hasufell <hasufell@gentoo.org> wrote:
> On 08/20/2015 07:42 PM, Michał Górny wrote:
>> As an alternative, we would use USE=client and USE=server along with
>> proper IUSE defaults to control client & server builds appropriately.
>> Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
>> is rather clear.
>>
>> Does anyone see any real problems with that?
>>
>
> That increases the burden of managing configuration and further abuses
> REQUIRED_USE where it wasn't meant to be used in the first place.
>

I don't think Michał is encouraging the use of REQUIRED_USE.  It would
only be used in cases where you could only install a client or a
server, but not both.  I imagine that would happen rarely, if ever.

I support this approach.  Lots of other client/server packages are
moving in this direction, or even splitting the client/server into
separate packages in some cases (I'm not suggesting making the latter
mandatory).

The typical game would have IUSE="+client +server" and then users
could set -client if they want a dedicated server, or -server if they
want a dedicated client, or whatever.  It seems pretty intuitive to
me.

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[hasufell]

On 08/20/2015 09:32 PM, James Le Cuirot wrote:
> On Thu, 20 Aug 2015 20:03:26 +0200
> hasufell <hasufell@gentoo.org> wrote:
> 
>>> As an alternative, we would use USE=client and USE=server along with
>>> proper IUSE defaults to control client & server builds
>>> appropriately. Both flags use positive logic, and REQUIRED_USE='||
>>> ( client server )' is rather clear.
>>
>> That increases the burden of managing configuration and further abuses
>> REQUIRED_USE where it wasn't meant to be used in the first place.
>>
>> USE="dedicated" has worked fine for games users and no one has ever
>> complained. In fact, it is a _very_ convenient USE flag, which means
>> "no manual fiddling, this will be dedicated for sure".
> 
> I'm don't feel very strongly about it but as someone who is considering
> working on more games in the future, I like what mgorny has suggested.
> I don't think the micro-managing argument flies so well here because
> these flags are much less common than flags like qt. client and server
> would probably be enabled by default in most cases and I doubt there
> are any games where you can't have both. If there were a conflict then
> you would want to make a concious decision as it's more significant
> than choosing a GUI toolkit.
> 

So what is the gain?

* introducing more REQUIRED_USE constraints (because you must not
disable both client and server)
* breaking existing configuration of users
* migrating a lot of ebuilds for no practical gain

Can we please have QA not dictate us how we model our USE flags? Games
_are_ consistently handled.

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -1. The way "dedicated" is used in games ebuilds is a very established
term that all gamers know and expect to behave in a specific way. This
will mess with our users.

\
Also, this is retarded micro-management bullshit. QA doesn't need to
police every aspect of Gentoo.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJV1jkcAAoJENQqWdRUGk8BHegP/0iPBGOwMkYdBltT5FCNrrX4
B/PWDuYlauhRT6Ej5NNKnFPWpmON6VFxGUfiHLe/Nc+28uZn9exgMx5Qw6qlLGrh
GwDT456QvUtul5DXiOrZ5gWUNvxjQfsGtcpB7OP/zQ9EpYSkGPy/TfryrakDryOW
7YLkFi/EJY3higpL96HHNgNZoZmkVLqW62EAFkmCZcYRmBlR3ClpCPVv7iEMMvvz
b0CH4saIlR6rLOwQ/u+1DHaX9hOFyYXTQfhheiAxoLlYeltcbBn3WKlaGDrhzyl5
76/YKaUEyEs+TvFrjmlSWtoSHAFcTEUsGZaVDuaZq6qicoMDFgQXQDREczAvXnej
Azz81mCO22P9h3wRU9ZeyVzc3TUSLxB8pqwhZuKSg7EwgnoCkcJxcQnM6BlXJJwQ
pYuPbs7JT2DClYLZr1txfb1L0V1hILdBm81nI6KTeeVJ8kuLRugDiiXsrZwJI/nZ
eeClOFa8d/XB6LIMgmNhH165WxkMnwgCdjFQRe22+KBlZkaNr9UQsK65jKHXVX4J
IimQ2P8Q3SI7rPG5rgo7mZvcqbV3NElroieVUvTumsi2+0KV+yt7bRMoBx57zq1T
/jBOR5/zEpPWAo3WaVuiCGHnGYeDhr3qrSz+xR8EtOyTX+Jqw9oqNKnKiHnl5U4p
syJ4Umd7wMGxTksFwxf9
=iO0l
-----END PGP SIGNATURE-----

[gentoo-dev] Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Martin Vaeth]

Alexander Berntsen <bernalex@gentoo.org> wrote:
>
> - -1. The way "dedicated" is used in games ebuilds is a very established
> term that all gamers know and expect to behave in a specific way.
> This will mess with our users.

How do you know what the users know and expect?
When installing a game, I was regularly surprised by the meaning
of this USE-flag and had to read its description several times
to be sure that I understand what is going on.
Remember that not only permanent gamers install games occassionally.

Re: [gentoo-dev] Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[hasufell]

On 08/20/2015 11:19 PM, Martin Vaeth wrote:
> Alexander Berntsen <bernalex@gentoo.org> wrote:
>>
>> - -1. The way "dedicated" is used in games ebuilds is a very established
>> term that all gamers know and expect to behave in a specific way.
>> This will mess with our users.
> 
> How do you know what the users know and expect?
> When installing a game, I was regularly surprised by the meaning
> of this USE-flag and had to read its description several times
> to be sure that I understand what is going on.
> Remember that not only permanent gamers install games occassionally.
> 
> 

It is used to set up a pure dedicated server, whatever that may mean for
a particular package (not just -client). You don't want to figure out
such details if you are setting this up on a real server. You want to
set it and be good.

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

This seems quite reasonable, and I welcome QA's efforts at maintaining
uniformity and cleanliness.

+1
On Aug 20, 2015 7:43 PM, "Michał Górny" <mgorny@gentoo.org> wrote:

> Hi,
>
> Right now, a number of game packages are using USE=dedicated to control
> 'installing a dedicated game server only'. Aside to that, some game
> packages also have USE=server that controls building the server itself.
> Non-game package use USE=client and USE=server.
>
> In order to improve uniformity of USE flags across different packages,
> the QA team would like to deprecate USE=dedicated and use USE=client
> and USE=server as appropriate.
>
> The problems I see with USE=dedicated are:
>
> - it is game-specific. The term 'dedicated server' is not used amongst
>   other server/client model packages.
>
> - It uses negative logic. Instead of enabling something, it disables
>   client. Pretty much 'dedicated' == 'noclient'. Negative logic is
>   confusing.
>
> - In packages having USE=server as well, it can lead to really absurd
>   combinations, like what does 'USE=dedicated -server' mean? Will it
>   build no executables at all? If we add REQUIRED_USE='dedicated?
>   ( server )', this gets quite unfriendly.
>
> As an alternative, we would use USE=client and USE=server along with
> proper IUSE defaults to control client & server builds appropriately.
> Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
> is rather clear.
>
> Does anyone see any real problems with that?
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
>

[-- Attachment #2: Type: text/html, Size: 2096 bytes --]

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[hasufell]

On 08/21/2015 12:06 AM, Jason A. Donenfeld wrote:
> This seems quite reasonable, and I welcome QA's efforts at maintaining
> uniformity and cleanliness.
> 

Like allowing that devs may or may not use games.eclass, so that users
cannot expect consistent behavior for games anymore?

Instead of ignoring the games project _again_ and making decisions above
their heads... try to fix the project maybe?

Is this becoming a habit now? People who are rarely involved in any
games ebuild development suddenly know how games ebuild consistency
should look like.

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Thu, Aug 20, 2015 at 6:18 PM, hasufell <hasufell@gentoo.org> wrote:
> On 08/21/2015 12:06 AM, Jason A. Donenfeld wrote:
>> This seems quite reasonable, and I welcome QA's efforts at maintaining
>> uniformity and cleanliness.
>>

++

I'd rather see groups like QA making proposals to improve cross-Gentoo
consistency than see stagnation.  It was an RFC, and people can post
issues with it, or escalate to Council if they're concerned.  If
taking it to Council I'd suggest you might want to come up with a
better argument than "who cares about consistency?"

As far as effort to remediate goes - there is no reason something like
this couldn't be incorporated in future bumps/changes/etc.

>
> Like allowing that devs may or may not use games.eclass, so that users
> cannot expect consistent behavior for games anymore?

That wasn't a QA decision, it was a Council decision.  We didn't
outright ban the eclass because we were hoping somebody would step up
to lead the games team and clean things up.

If you're proposing an outright ban on games.eclass and a move towards
treating games like other packages you can petition the Council like
anybody else.

> Instead of ignoring the games project _again_ and making decisions above
> their heads... try to fix the project maybe?

Are you offering to do that?

The issue is that nobody seems to want to take over the games project.
You can't force people to join a dead team.  It doesn't make sense to
prevent progress either just to call attention to a dead team.

>
> Is this becoming a habit now? People who are rarely involved in any
> games ebuild development suddenly know how games ebuild consistency
> should look like.
>

This isn't about games consistency.  This is about tree consistency.
The games were already consistent with the dedicated USE flag.  The
problem is that they're doing it differently than virtually everything
else, in a way that doesn't make as much sense.

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Thu, 2015-08-20 at 19:42 +0200, Michał Górny wrote:
> Hi,
> 
> Right now, a number of game packages are using USE=dedicated to control
> 'installing a dedicated game server only'. Aside to that, some game
> packages also have USE=server that controls building the server itself.
> Non-game package use USE=client and USE=server.
> 
> In order to improve uniformity of USE flags across different packages,
> the QA team would like to deprecate USE=dedicated and use USE=client
> and USE=server as appropriate.
> 
> The problems I see with USE=dedicated are:
> 
> - it is game-specific. The term 'dedicated server' is not used amongst
>   other server/client model packages.

Please leave the flag as is - for those users who will be using those
ebuilds to install and run dedicated game servers, it's standard and
expected terminology.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Kent Fredric]

On 21 August 2015 at 13:03, Rich Freeman <rich0@gentoo.org> wrote:
> I'd rather see groups like QA making proposals to improve cross-Gentoo
> consistency than see stagnation.  It was an RFC, and people can post
> issues with it, or escalate to Council if they're concerned.  If
> taking it to Council I'd suggest you might want to come up with a
> better argument than "who cares about consistency?"


Consistency is a fine goal, but "global" consistency can cost local
consistency in detrimental ways.

Hence why "DSLs" exist. For instance if we decided to make all sports
consistent, we'd have 3 games where people hit balls with bats, and
alternated between running with them and kicking them, and they'd all
be consistent, but the game itself would become confusing and
pointless.

I think its fine for some parts of trees to have local standards, so
that people using those parts of trees the most get the benefits out
of huffmanization.

No vote from me, I just don't see a point in changing something that
isn't broken for the sake of change, where the result may be a net
detriment and increase in complexity for consumers.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

[gentoo-dev] Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Duncan]

Rich Freeman posted on Thu, 20 Aug 2015 15:56:11 -0400 as excerpted:

> On Thu, Aug 20, 2015 at 2:03 PM, hasufell <hasufell@gentoo.org> wrote:
>> On 08/20/2015 07:42 PM, Michał Górny wrote:
>>> As an alternative, we would use USE=client and USE=server along with
>>> proper IUSE defaults to control client & server builds appropriately.
>>> Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
>>> is rather clear.
>>>
>>> Does anyone see any real problems with that?
>>>
>>>
>> That increases the burden of managing configuration and further abuses
>> REQUIRED_USE where it wasn't meant to be used in the first place.
>>
>>
> I don't think Michał is encouraging the use of REQUIRED_USE.  It would
> only be used in cases where you could only install a client or a server,
> but not both.  I imagine that would happen rarely, if ever.
> 
> I support this approach.  Lots of other client/server packages are
> moving in this direction, or even splitting the client/server into
> separate packages in some cases (I'm not suggesting making the latter
> mandatory).
> 
> The typical game would have IUSE="+client +server" and then users could
> set -client if they want a dedicated server, or -server if they want a
> dedicated client, or whatever.  It seems pretty intuitive to me.

Hasufell's arg is (as I read it) the -server -client case.

Are you saying USE="-server -client" shouldn't have a REQUIRED_USE 
either?  If not, what are you suggesting for that case?

FWIW, with IUSE defaults, the only people who should see that case are 
those who either specifically set USE="-client -server", or those (like 
me) using USE=-*.  And in both cases, I'd say REQUIRED_USE or not, people 
are getting /exactly/ what they ask for, and get to keep the pieces, 
either a REQUIRED_USE message or a non-functional package, as a result.  
IMO, that's NOTABUG.  After all, games don't tend to be somewhere down 
below the radar in the don't-care stack, like libs and toolkits, and if 
people end up with a non-functional game package because they 
specifically disabled both server and client, so be it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] games.eclass (was: Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server)

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

>>>>> On Fri, 21 Aug 2015, hasufell  wrote:

> Like allowing that devs may or may not use games.eclass, so that
> users cannot expect consistent behavior for games anymore?

Sorry, but that is not accurate. Usage of games.eclass has been
deprecated by QA [1] (with the council's mandate [2]), so devs should
not use it any longer.

Maybe QA should be stricter in enforcing its policies, in order to
avoid such false impressions in future?

Ulrich

[1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue
[2] https://projects.gentoo.org/council/meeting-logs/20140812-summary.txt

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

20.08.2015 20:42, Michał Górny пишет:
> Hi,
> 
> Right now, a number of game packages are using USE=dedicated to control
> 'installing a dedicated game server only'. Aside to that, some game
> packages also have USE=server that controls building the server itself.
> Non-game package use USE=client and USE=server.
> 
> In order to improve uniformity of USE flags across different packages,
> the QA team would like to deprecate USE=dedicated and use USE=client
> and USE=server as appropriate.
> 
> The problems I see with USE=dedicated are:
> 
> - it is game-specific. The term 'dedicated server' is not used amongst
>   other server/client model packages.
> 
> - It uses negative logic. Instead of enabling something, it disables
>   client. Pretty much 'dedicated' == 'noclient'. Negative logic is
>   confusing.
> 
> - In packages having USE=server as well, it can lead to really absurd
>   combinations, like what does 'USE=dedicated -server' mean? Will it
>   build no executables at all? If we add REQUIRED_USE='dedicated?
>   ( server )', this gets quite unfriendly.
> 
> As an alternative, we would use USE=client and USE=server along with
> proper IUSE defaults to control client & server builds appropriately.
> Both flags use positive logic, and REQUIRED_USE='|| ( client server )'
> is rather clear.
> 
> Does anyone see any real problems with that?
> 

<qa team lead hat>
While i am all for unification, i do not think that this is the case,
where QA should be involved. "Dedicated server" is established phrase,
that all users, who wants to maintain such services, know. So, i do not
think that our direct interaction is needed here. If we want to change
something in this direction - it should be done in tight connection with
Games team
</qa team lead hat>

Ok, now my personal opinion follows. USE flag description for
'dedicated' is contrintuitive for me.

 - - dedicated : Add support for dedicated game servers (some packages
do not provide clients and servers at the same time)

It seems that it build ONLY servers for some packages and for others -
it allows you to have dedicated server IN ADDITION to regular client.
That's confusing.

Now, THAT should be fixed either way - by moving 'dedicated' to
'server'(for those packages), or, preferabbly - by allowing
USE='dedicated' to work as hasufell said - build ONLY dedicated server
and no client at all.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Kent Fredric]

On 21 August 2015 at 19:16, Sergey Popov <pinkbyte@gentoo.org> wrote:
> Now, THAT should be fixed either way - by moving 'dedicated' to
> 'server'(for those packages), or, preferabbly - by allowing
> USE='dedicated' to work as hasufell said - build ONLY dedicated server
> and no client at all.


Another compromise that *could* work if the installation is so
structured: Split the server behaviour into its own package.

games-whatever/foo             + IUSE="server"
games-whatever/foo-server

That completely eliminates the required_use confusion. "foo" is always
providing a client, and USE="server" is just a convenience that few
will want.

If you want a server, install "foo-server".

Granted this is of course not always possible if the server and client
share files, but such a solution would be high on my considerations
were it me.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Daniel Campbell (zlg)]

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

On 08/20/2015 10:42 AM, Michał Górny wrote:
> Hi,
> 
> Right now, a number of game packages are using USE=dedicated to
> control 'installing a dedicated game server only'. Aside to that,
> some game packages also have USE=server that controls building the
> server itself. Non-game package use USE=client and USE=server.
> 
> In order to improve uniformity of USE flags across different
> packages, the QA team would like to deprecate USE=dedicated and use
> USE=client and USE=server as appropriate.
> 
> The problems I see with USE=dedicated are:
> 
> - it is game-specific. The term 'dedicated server' is not used
> amongst other server/client model packages.
> 
> - It uses negative logic. Instead of enabling something, it
> disables client. Pretty much 'dedicated' == 'noclient'. Negative
> logic is confusing.
> 
> - In packages having USE=server as well, it can lead to really
> absurd combinations, like what does 'USE=dedicated -server' mean?
> Will it build no executables at all? If we add
> REQUIRED_USE='dedicated? ( server )', this gets quite unfriendly.
> 
> As an alternative, we would use USE=client and USE=server along
> with proper IUSE defaults to control client & server builds
> appropriately. Both flags use positive logic, and REQUIRED_USE='||
> ( client server )' is rather clear.
> 
> Does anyone see any real problems with that?
> 
Based on what I'm seeing in this thread, the problem seems to center
around the description and application of the `dedicated` flag. I'm
fully in favor of the `server` and `client` flags because they're
clear and consistent.

*However*, it was mentioned elsewhere in the thread that some games
don't allow a client and a server at the same time. Personally I find
that behavior odd and indicative of poor design, and I think packages
that can't be built that way should have REQUIRED_USE or simply a
`foo-server` package to unambiguously show that they're server-only.

I'd rather see something to make client+server work for every single
game instead of forcing people to use other packages or pick and
choose; I see no reason why a gamer should have to choose between
client and server. There's a perfectly legitimate use case of someone
who hosts their own server but also plays the game, either on their
own server or on someone else's. With an 'either or' approach, that
use case is impossible. Those ebuilds need to be fixed. If any games I
played were that way, I'd gladly help out with that.

As it stands, I haven't figured out how to get a few games I'd like to
see in the tree (Wizorb and A Virus Named Tom). With the games.eclass
deprecated, I don't really have a "good practice" guide for making
gaming ebuilds.

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

iQIcBAEBCAAGBQJV1uHfAAoJEAEkDpRQOeFwdK8P/2iiwl3Nt1om4GOPe4OkZA8u
a+ad28vmiFMOTchBU8Gdouom0ZFPIWNluxCfLzUNc5kMArDAUXUSqAudaloyYTVx
q7x+6ihHGAchefVHT9xPVh/ny0gmKEIkLL6lFkPGGfP7cpv2Rucn4djIr6RPS4WV
Ju3tZZifiemUUlfoOx836mUGOeRtWP8AcbeuAYu+ruB6gJmryQKUbuD6ezIEmgVy
MAFjYCQZ4gx1NyzjlN1v5j+eLeDh+HoTQlJkECc2NWY1ULOkdWvjCpRMcjmKXDgI
db6Cazs70jqQr/QIX7XcRPyemnci/wZqzJ6uzVZSM2LSn74Tbqvyu3ch5wzDKMlS
VnF3LRx7YlM1+ggqVxFxOm3rjjLsUHdnoSzPYQCW0TwLPU+acwFHtDDUqBxkRyEg
UCXa1I60AAbXf4QjPQG5S3P9eOKAal4iPfsf8IiQSHMpOUwgrA+4qK+amhr3nkwg
g5TsWB9GkBndlYKxQyXiDwTPuZvZtDhjbfhddhLa/bmWV4LpcaTSDgRrmFXkv4oP
9cNdygCa2TdBMfd/9duenedaHgDhhvVNPhSsDPHTAP0vesXr7ntK41V9RDMgm0w5
CZAPYOr6Ew5v2SeK+hFwoVfjdpmmCHGtrqBjIfyzHTUuHj/YSFTDxRWaZVjS/m6o
vXKxlcB2TySZX6pCZRje
=LqFQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Fri, Aug 21, 2015 at 4:31 AM, Daniel Campbell (zlg) <zlg@gentoo.org> wrote:
> Based on what I'm seeing in this thread, the problem seems to center
> around the description and application of the `dedicated` flag. I'm
> fully in favor of the `server` and `client` flags because they're
> clear and consistent.

++

> *However*, it was mentioned elsewhere in the thread that some games
> don't allow a client and a server at the same time.

Can we actually get an example of one before we go making policy based
on what seems like a really strange case (one which I'm skeptical
actually exists)?

It seems that in these cases either REQUIRED_USE gets used, but
preferentially the build system should be fixed or the package should
be split.

> With the games.eclass deprecated, I don't really have a "good practice" guide
> for making gaming ebuilds.

Just make them like any other ebuild.  The main thing games.eclass did
was force users to be in the games group to run games, and install
them in a special location.

The eclass isn't officially deprecated, but it probably should be.
You should install a game just like you'd install a word-processor or
a web browser.  It is just another desktop application (99% of the
time).

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Fri, Aug 21, 2015 at 3:16 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:
>
> <qa team lead hat>
> While i am all for unification, i do not think that this is the case,
> where QA should be involved. "Dedicated server" is established phrase,
> that all users, who wants to maintain such services, know. So, i do not
> think that our direct interaction is needed here. If we want to change
> something in this direction - it should be done in tight connection with
> Games team
> </qa team lead hat>
>

Regardless of QA team involvement, it still sounds like a good
direction to take, and I'm fine with just adding this to the next
council agenda if the QA team declines to take it on (proposal would
be to ban the dedicated flag in favor of client and server or
splitting ebuilds).

I don't actually see this as a "games" thing.  If it really were a
games thing then I'd say leave it up to the games team (though as long
as one doesn't actually exist I think we probably should fix huge
eyesores).

I attached lists of all packages that IUSE dedicated, server, and
client.  You'll notice that some games actually use server already.

Oh, and on the first ebuild that uses server (turtlearena) that I
checked I found these gems:
        BUILD_CLIENT=$(nobuildit dedicated) \
        BUILD_SERVER=$(usex dedicated "1" "$(buildit server)") \
...
        if ! use dedicated ; then
<< install client >>
        fi

        if use dedicated || use server ; then
<< install server >>
        fi

Please tell me again how this is cleaner than just having a client and
a server USE flag, with appropriate defaults (which can vary by
package already)?

Looks like the one non-game that uses dedicated also users server
(sci-mathematics/rstudio) and its ebuild has more of the same.  I
don't suppose we should ask the games team to clean that one up too?

Some things really do make sense as tree-wide defaults, IMHO.  That
said, I'm perfectly fine with the QA team wanting to see this handled
by the council - this is on the edges of their responsibility areas.

Please don't look at this as some committee imposing arbitrary rules
or creating work.  Inconsistency like this is user-visible and it
violates the principle of least-surprise.  I don't fault the games
maintainers for where they ended up - their practice is far older than
the server+client approach.  However, the latter seems much cleaner,
and for cases like mysql where the client gets really heavy use I
applaud their decision to go further and split the package.

Somebody made the argument that sometimes having consistency within
domains matters more than global consistency.  I can buy that
argument, but I don't think this is one of those cases.

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Fri, Aug 21, 2015 at 6:31 AM, Rich Freeman <rich0@gentoo.org> wrote:
> The eclass isn't officially deprecated, but it probably should be.
> You should install a game just like you'd install a word-processor or
> a web browser.  It is just another desktop application (99% of the
> time).

Ugh, I should have read ulm's email first.  I was right that the
council didn't deprecate the ebuild, but missed the memo on the games
team having done so.  It is in fact deprecated right now.  Guess I
should go fix my game (which didn't actually run last time I checked
anyway).  :)

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 21/08/15 12:58, Rich Freeman wrote:
> Somebody made the argument that sometimes having consistency
> within domains matters more than global consistency.  I can buy
> that argument, but I don't think this is one of those cases.
As an old-school gamer and someone who runs dedicated servers and have
done so for years, I disagree. So would a lot of gamers. The games
team and games ebuild users are primarily gamers. This will cause us
nothing but annoyance. Leave it, please.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJV1wtCAAoJENQqWdRUGk8Be2IP/RK2XRdZtGywR6O/DlVvg9yT
eoGQ4Wu8nC8YVSW1hLkMO2bOFta1oXqX2VH6SuBXxa6YXQHX2mmeSEFaGCP8p7xO
AJwO5Csyxc1QeChdLXi+mlQ53xAZohcg3005aDld5SABtSLxhmI9SCORUdIL9SMk
ijM0ISM3zfx0XZSoF183kXerR/AkRF0qD9Zxhc778JtCdLCh9toE0BsOoC/InJHs
3OnQqBxCJSBRQIpXBsbqEFm3lq1PW4ypkREwhl2eHWlJbY8AVvrLJuHHd4V61ELw
+jH4tLXZ1oWCpqFsy+szIQ4kJvvdzAcMoQBd7KK6nbHDwVPBWsffgr8I3f6bJoKS
LIPjQgcfoEY1ZJMAwFuhZywv4zz3tRkHIEQ4MF4n3gFEQ/4Wt8uj2yWCLA9Wv26N
ZnWEshVmxcF+Bfg9LepVaW51EGcMEGzoBz/NKtn8nphZhUwzZx7HTptMQj61Tj8l
DTbe11nJ1UxaZ+lr/dMpdDEMrG4+rnt4BVl6lETeIT2K2hxW97PpmCqMM6MSQlKB
pyEYjU3lOLxCvK2wWxKlduRQq8uf1qvp4ZPFXQKANu+EDBo9DtKT6qsWGYDQTzkp
msu7OoOzqQroYyOlySDWNXh69sxe8GBwUGfjjvMvbOeXj6OmhxMQ15kmWpwlJX/g
dFOBxadcBTcnFuuw78In
=ZXxF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Fri, Aug 21, 2015 at 7:28 AM, Alexander Berntsen <bernalex@gentoo.org> wrote:
> As an old-school gamer and someone who runs dedicated servers and have
> done so for years, I disagree. So would a lot of gamers.

As an old-school gamer I think the USE=client/server thing makes a lot
of sense.

So would a lot of gamers.

I get that some people don't like the proposal.  That is true of
virtually every proposal that goes to the council.

> The games
> team and games ebuild users are primarily gamers. This will cause us
> nothing but annoyance. Leave it, please.

I'm a gamer.  I suspect half of all Gentoo users play games.  The
games ebuild causes me nothing but annoyance.  It is already
deprecated.

I am not coming down on you for expressing your opinion.  That is your
right, and I've noted it.

We're already using client/server but doing it in a confusing way.
USE=dedicated means USE="+server -client"
USE=server means USE="+server +client"
USE=-server means USE="-server +client"
USE="dedicated -server" seems to generally be interpreted as
USE="+server -client"  (please tell me again how this is better than
REQUIRED_USE?)

But, I'm sure that a complete survey of packages would show the
current state to be more confused.

I'm just one vote, but if you really want to preserve the current
state I'd suggest bringing arguments and not "please leave us alone."
Right now there isn't even a functional games team to leave alone, and
this isn't just about games.

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Thu, 20 Aug 2015 20:03:26 +0200
hasufell <hasufell@gentoo.org> wrote:
> That increases the burden of managing configuration and further abuses
> REQUIRED_USE where it wasn't meant to be used in the first place.

Daily reminder that there's no such thing as "how REQUIRED_USE is meant
to be used in the first place", because REQUIRED_USE was introduced
without implementation, testing or design.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] games.eclass

[hasufell]

On 08/21/2015 08:50 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 21 Aug 2015, hasufell  wrote:
> 
>> Like allowing that devs may or may not use games.eclass, so that
>> users cannot expect consistent behavior for games anymore?
> 
> Sorry, but that is not accurate. Usage of games.eclass has been
> deprecated by QA [1] (with the council's mandate [2]), so devs should
> not use it any longer.
> 
> Maybe QA should be stricter in enforcing its policies, in order to
> avoid such false impressions in future?
> 
> Ulrich
> 
> [1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue
> [2] https://projects.gentoo.org/council/meeting-logs/20140812-summary.txt
> 


May I remind you that

"""
- Motion: "The council encourages the games team to accept join
  requests and elect a lead. In the event they don't elect a lead
  within 6 weeks, we will consider the team as dysfunctional and thus
  disband it."
  Accepted with 6 yes votes and 1 abstention.
"""

has never happened? There has been no vote, but the team has not been
considered dysfunctional. Instead we are just acting like it doesn't
exist, more or less. Sounds good?

It seems, that QA is currently an "intermediate games project policy
team". Is that its job? I don't think so. Maybe QA should have _less_ power.

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[hasufell]

On 08/21/2015 02:04 PM, Rich Freeman wrote:
> Right now there isn't even a functional games team to leave alone, and
> this isn't just about games.
> 

Exactly. Start there, instead of having the council or QA impose games
policies. It's not their job.

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Rich Freeman]

On Fri, Aug 21, 2015 at 11:27 AM, hasufell <hasufell@gentoo.org> wrote:
> On 08/21/2015 02:04 PM, Rich Freeman wrote:
>> Right now there isn't even a functional games team to leave alone, and
>> this isn't just about games.
>>
>
> Exactly. Start there, instead of having the council or QA impose games
> policies. It's not their job.
>

Sure it is.  These are tree consistency issues.  And every project
falls under the scope of the Council.  That's what it is there for.

If there is something you want us to do to make the games team start
working feel free to suggest it.  We're all volunteers.  You can't
force people to join the games team.

Do you really want me to just join the games team myself, elect myself
lead, and then impose sensible policies by fiat?  I don't think that
this is any better than having a discussion on the lists, and then
having the Council take a vote.  If somebody were stepping up and
saying that they've got this one I'd be inclined to give them some
runway to do it.

-- 
Rich

Re: [gentoo-dev] games.eclass

[Rich Freeman]

On Fri, Aug 21, 2015 at 11:10 AM, hasufell <hasufell@gentoo.org> wrote:
> On 08/21/2015 08:50 AM, Ulrich Mueller wrote:
>>>>>>> On Fri, 21 Aug 2015, hasufell  wrote:
>>
>>> Like allowing that devs may or may not use games.eclass, so that
>>> users cannot expect consistent behavior for games anymore?
>>
>> Sorry, but that is not accurate. Usage of games.eclass has been
>> deprecated by QA [1] (with the council's mandate [2]), so devs should
>> not use it any longer.
>>
>> Maybe QA should be stricter in enforcing its policies, in order to
>> avoid such false impressions in future?
>>
>> Ulrich
>>
>> [1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue
>> [2] https://projects.gentoo.org/council/meeting-logs/20140812-summary.txt
>>
>
>
> May I remind you that
>
> """
> - Motion: "The council encourages the games team to accept join
>   requests and elect a lead. In the event they don't elect a lead
>   within 6 weeks, we will consider the team as dysfunctional and thus
>   disband it."
>   Accepted with 6 yes votes and 1 abstention.
> """
>
> has never happened? There has been no vote, but the team has not been
> considered dysfunctional. Instead we are just acting like it doesn't
> exist, more or less. Sounds good?

Well, we did say we would disband it.  We just didn't follow through.
Would you be happier if we did disband it?

The goal was to try to leave the structure there in case anybody steps
up, but I don't really see the harm in acting as if the team doesn't
exist.  It essentially doesn't.  Disbanding it would just make it
formal.

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.

-- 
Rich

Re: [gentoo-dev] games.eclass

[hasufell]

On 08/21/2015 07:39 PM, Rich Freeman wrote:
> On Fri, Aug 21, 2015 at 11:10 AM, hasufell <hasufell@gentoo.org> wrote:
>> On 08/21/2015 08:50 AM, Ulrich Mueller wrote:
>>>>>>>> On Fri, 21 Aug 2015, hasufell  wrote:
>>>
>>>> Like allowing that devs may or may not use games.eclass, so that
>>>> users cannot expect consistent behavior for games anymore?
>>>
>>> Sorry, but that is not accurate. Usage of games.eclass has been
>>> deprecated by QA [1] (with the council's mandate [2]), so devs should
>>> not use it any longer.
>>>
>>> Maybe QA should be stricter in enforcing its policies, in order to
>>> avoid such false impressions in future?
>>>
>>> Ulrich
>>>
>>> [1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue
>>> [2] https://projects.gentoo.org/council/meeting-logs/20140812-summary.txt
>>>
>>
>>
>> May I remind you that
>>
>> """
>> - Motion: "The council encourages the games team to accept join
>>   requests and elect a lead. In the event they don't elect a lead
>>   within 6 weeks, we will consider the team as dysfunctional and thus
>>   disband it."
>>   Accepted with 6 yes votes and 1 abstention.
>> """
>>
>> has never happened? There has been no vote, but the team has not been
>> considered dysfunctional. Instead we are just acting like it doesn't
>> exist, more or less. Sounds good?
> 
> Well, we did say we would disband it.  We just didn't follow through.
> Would you be happier if we did disband it?
> 

I don't know. Stick to your word, maybe?

So far, neither the council, nor QA, nor ComRel were particularly
helpful with the situation.

And QA "proxying" policy-discussions/decisions for a non-functional team
is not a solution (the thread has a clear "QA:" prefix and I don't think
that was by accident).

If the team is disbanded, then regular tree policy applies and
everything goes through the regular community discussion/decision
channels without the need of QA putting their prefixes/hats everywhere.

If a new team is constituted, then they might establish new policies,
also without QA dictating anything. And I would give that some time,
which means don't start funny mass commits/conversions.

[gentoo-dev] Re: QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Duncan]

hasufell posted on Fri, 21 Aug 2015 17:27:06 +0200 as excerpted:

> On 08/21/2015 02:04 PM, Rich Freeman wrote:
>> Right now there isn't even a functional games team to leave alone, and
>> this isn't just about games.
>> 
>> 
> Exactly. Start there, instead of having the council or QA impose games
> policies. It's not their job.

Kinda hard to start by fixing the game team, with gentoo being a 
community-volunteer based project, and apparently no devs interested in 
volunteering for games lead.  The council can ask for volunteers and they 
have, but as the saying goes, you can lead a horse to water but you can't 
make him drink, and if nobody's volunteering to drink the games-lead 
drink...

Which of course has been pointed out numerous times...

Without that games team, the slack has to be picked up somewhere, and 
ultimately it falls to the QA and tree-cleaners teams, which /are/ still 
active, do do it.  And if they're going to do it, in the absence of a 
working games team despite asking for volunteers multiple times, it's 
reasonable to expect they'll remake it in their own image, to some 
degree, which is pretty much exactly what this thread is about.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] games.eclass

[Rich Freeman]

On Fri, Aug 21, 2015 at 2:17 PM, hasufell <hasufell@gentoo.org> wrote:
>
> I don't know. Stick to your word, maybe?

I'm glad we have you here to be our conscience.  :)

I'm sure this will go on the next agenda.  However, the decision to
kick the can was actually an intentional one.  We were hoping to see
more interest in fixing the games team and it didn't turn up.  We
didn't want to cause more harm than good.

>
> So far, neither the council, nor QA, nor ComRel were particularly
> helpful with the situation.

Well, the problem is that nobody wants to clean up games.  Short of
the council members joining the games team and doing the work
themselves there isn't really anything that is going to make you
happy.  Another solution is to just treeclean all the games, and that
certainly isn't going to make anybody happy.

We get it.  Everybody wants somebody else to spend a lot of time doing
something that will make their life easier for free.  It is a pretty
common theme in FOSS.  Certainly we're not the only distro where I've
seen this sort of complaint come up.

I think we try to find a good balance in Gentoo in empowering devs and
still providing most of the benefits of centralization to users and
each other.

>
> If the team is disbanded, then regular tree policy applies and
> everything goes through the regular community discussion/decision
> channels without the need of QA putting their prefixes/hats everywhere.

So far the QA team hasn't done anything at all on this issue.  In fact
the QA lead suggested that he didn't want to take the initiative.
Perhaps you should wait for QA to actually do something before you
appeal it to the council, and wait for the council to deny your appeal
before you complain about it here.

And QA doesn't just govern packages maintained by project teams.  In
fact, those are the sorts of packages they /should/ have to spend the
least time worrying about.  Of course, they're free to pursue policy
violations wherever they see them.

In any case, I don't find the whole argument about "who has permission
to implement this really good idea" debate very helpful.  I'd rather
focus on whether it is a really good idea.  If it is, let's make it
happen.

I don't want to turn into Debian where after it is clear that most
people want something to happen they go back and forth for six months
with 14 resolutions and 12 committees and 85 appeals to parliamentary
procedure all arguing over who has the power to do what.  Heaven
forbid that there are two developers somewhere who are forced to do
something without as much due process as the US government affords
people accused of murder.  This isn't the US Senate.  If devs ever
want that kind of operation, do me a favor and elect somebody else to
Council.

This is just a discussion right now.  I think most of the arguments
pro and con have been made, and if there are others people can make
them.

I just don't think it is helpful to argue about who is allowed to
raise the topic in the first place, or who is allowed to make the
decision.  QA has fairly broad discretion in our current setup, and
the Council has jurisdiction over just about anything that isn't
financial/legal in nature.  Heck, some have argued for having a
project leader / dictator role to cut through red tape.  We don't need
to argue about whether we're allowed to make progress.

>
> If a new team is constituted, then they might establish new policies,
> also without QA dictating anything. And I would give that some time,
> which means don't start funny mass commits/conversions.
>

Well, that "new team" has had months since they failed to resolve the
last crisis, and it has weeks before the next council meeting.  If the
"new team" hasn't even gotten around to acting like they actually
exist by then, I wouldn't expect everybody else to hold their breath.

-- 
Rich

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

[Daniel Campbell (zlg)]

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

On 08/21/2015 03:31 AM, Rich Freeman wrote:
> On Fri, Aug 21, 2015 at 4:31 AM, Daniel Campbell (zlg)
> <zlg@gentoo.org> wrote:
>> Based on what I'm seeing in this thread, the problem seems to
>> center around the description and application of the `dedicated`
>> flag. I'm fully in favor of the `server` and `client` flags
>> because they're clear and consistent.
> 
> ++
> 
>> *However*, it was mentioned elsewhere in the thread that some
>> games don't allow a client and a server at the same time.
> 
> Can we actually get an example of one before we go making policy
> based on what seems like a really strange case (one which I'm
> skeptical actually exists)?

I'm not aware of such use-case, as it was mentioned by someone else.
It's a theoretical possibility, though, and games aren't always known
for having sane build systems or programming practices, so I think
it's worth considering.

> 
> It seems that in these cases either REQUIRED_USE gets used, but 
> preferentially the build system should be fixed or the package
> should be split.

Agreed.
> 
>> With the games.eclass deprecated, I don't really have a "good
>> practice" guide for making gaming ebuilds.
> 
> Just make them like any other ebuild.  The main thing games.eclass
> did was force users to be in the games group to run games, and
> install them in a special location.
> 
> The eclass isn't officially deprecated, but it probably should be. 
> You should install a game just like you'd install a word-processor
> or a web browser.  It is just another desktop application (99% of
> the time).
> 

Thanks, I'll keep that in mind when I get around to writing those
ebuilds. I'll also consult the games team before committing.

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

iQIcBAEBCAAGBQJV13ylAAoJEAEkDpRQOeFwWgsQAKYTlKXP1bgyN68cDbVddnfE
kgggdVy3R2Zv0AHRfqbip4prrbbDv5+M0qifQ8RGa9WxQ4Fu5kVxUrFsJ1l2xO7O
VNSYDeBl4NVC+AqePDSsqzKCWojYR8hMbEhBvsC3hsxGeD28dBJ5P3yhQMHORvSy
T2K45wj/lXlJDKTrnI/3cwpWSNJM6u209pXLlU6XydsXt0lh9C+3pV2NGNuXuucw
jSkA2cGxRCGQqaGxWcVjXyPr2tRkWsFYr1kxyNqaJ7Meb9kX5QUFzkwBZAWR6Eq4
HV7kiM8CLujDJapbN2NwpsBs6Bo5e4jlJwmw8+kOLeMVXBbZFzf5q/vy3+vB9hds
ibGEc90tdEb+zo6lHMD8EhI7OlR5ckJ4yuLykzYqanB5bLzBXA9OKe/IgUtgrtVT
RadKh0v42Qo6Rck1uzCus0ZiTME1cykvvyrz+wQIvl1PHrdArwtqPNSIOtVGnngt
W2cjJUVs8bE2JA/ftHjrj7cLrsSicvJ9aRKCZLNMFHJIs7Wq923wQTCVZ/8/mhsf
Z2eX74plPuwk6H/8EmJPNTW2JmA5R2t759chJcaSfEW/Tgc0w1nsoMUCWnwxjF5E
x2Qxx5P7I0kEVqYXCJ2Z14NtRafO+Oq31t9OcxGuRYv/r/dK17w70uA652jr8FmX
arJW7R1aiYqch1p6FKhM
=Y7o9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] games.eclass

[Daniel Campbell (zlg)]

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

On 08/21/2015 10:39 AM, Rich Freeman wrote:
> On Fri, Aug 21, 2015 at 11:10 AM, hasufell <hasufell@gentoo.org>
> wrote:
>> On 08/21/2015 08:50 AM, Ulrich Mueller wrote:
>>>>>>>> On Fri, 21 Aug 2015, hasufell  wrote:
>>> 
>>>> Like allowing that devs may or may not use games.eclass, so
>>>> that users cannot expect consistent behavior for games
>>>> anymore?
>>> 
>>> Sorry, but that is not accurate. Usage of games.eclass has
>>> been deprecated by QA [1] (with the council's mandate [2]), so
>>> devs should not use it any longer.
>>> 
>>> Maybe QA should be stricter in enforcing its policies, in order
>>> to avoid such false impressions in future?
>>> 
>>> Ulrich
>>> 
>>> [1]
>>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summa
ries#Games_team_policies_issue
>>>
>>> 
[2] https://projects.gentoo.org/council/meeting-logs/20140812-summary.tx
t
>>> 
>> 
>> 
>> May I remind you that
>> 
>> """ - Motion: "The council encourages the games team to accept
>> join requests and elect a lead. In the event they don't elect a
>> lead within 6 weeks, we will consider the team as dysfunctional
>> and thus disband it." Accepted with 6 yes votes and 1
>> abstention. """
>> 
>> has never happened? There has been no vote, but the team has not
>> been considered dysfunctional. Instead we are just acting like it
>> doesn't exist, more or less. Sounds good?
> 
> Well, we did say we would disband it.  We just didn't follow
> through. Would you be happier if we did disband it?
> 
> The goal was to try to leave the structure there in case anybody
> steps up, but I don't really see the harm in acting as if the team
> doesn't exist.  It essentially doesn't.  Disbanding it would just
> make it formal.
> 
> 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.

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

iQIcBAEBCAAGBQJV138OAAoJEAEkDpRQOeFwSbAP/jBciQLb6oHqNyiXUEIyEWtq
ja1arNrRtgLq3x6invviwB+AilkFPAcyVHGJkrwDxRPN0Ykt/VZ3Raf3BF4asCM8
zRTwEJHGvf+JsShMM5dujqdArhfoGNuRjdCNY8QfveVzBBDGtWLM6zGA/rhc/jDG
0OkLkaFiTSx6qy9aEDoj+PfBSpZcEdNSWx3zxthrWbnFO3qD6hgy8PUizwsRM2+t
PKvD6t6uaraql15+dcFGosiT9KgwjvONvEHaH12T8n73VR3xgbYFo1zM44LbQ8kH
h90zjOU7rKKy6Pplbqvz6rlWpytOq5+KrLuikYnd4wcmLxYEq/NWzsStOVUNq1Vn
IeUyxTjxRgpHvdlNgxiqgVpbAGxR7uR0DM1Ayj7K0ow1b2jRu+/A6XLn7spV+f3Z
fPA0Kz/FO7lEaOn561ENdBd6QUAYf5zpNlOVyD+GSWGUWsCp3fwqfZc/xSXetzCL
TyYJlcvpEFcwzUSxactkVqCLIAaxubxna0SnNclBVoIrocvOk9MF7ayCXHNRX2uC
nW01Ye50x1WsHflzLyHEVZrh6uaovhBqqvAwkD0+FW4jeJnO5fTfkHzcB8egqk78
0K5K5u25cuGpteVIzvFdudxEEm9Owf5NdZkdrX5ay61HSB4QmOfHRmnbJk1xOj+u
wFjThVYPKxIyASR6uhun
=FlQB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] games.eclass

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

On Fri, 21 Aug 2015 12:42:07 -0700
"Daniel Campbell (zlg)" <zlg@gentoo.org> 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.

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.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] games.eclass

[Daniel Campbell (zlg)]

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

On 08/21/2015 02:09 PM, James Le Cuirot wrote:
> On Fri, 21 Aug 2015 12:42:07 -0700 "Daniel Campbell (zlg)"
> <zlg@gentoo.org> 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.

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.

I think hasufell works on games... thoughts?

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

iQIcBAEBCAAGBQJV2CW8AAoJEAEkDpRQOeFwmD4QAK+XDYvgKngBsF2PAZahSrSz
zxkp3fRdkTf81ZojI5u3bqby15n93026FoIXCkWEdjcJnV4xIxGDLSqIJ7BfxObS
MtGsk48upYO3K0/af4AYCLOU7P8B22SNrkgCYyS0v++4ZOEkdLV+i2TdCXwSEXNW
lJig9X3iot1oYRsHHNnmlfPhkHgZsaeox48m1DazxlcWbVDHvcq8kiATaUyOLB1O
+nOJEXBMI9bXaUjCW7kX7OGROJrzP6zpU/lGoEE4+jHg1X39chlIUJnJbaBkcHUG
MoUc25NLB72C+dPhnsQQPMh/MA4bI6K2IhpIWR1Pthebb+GslwBMxxKkxop+tRpV
2nuz9qRRqVQWN55ugwBlFhG8nUA+jIIFaWNKl/4sF9FyZ1AT/yoZYldvlRF6OtT2
sm9H0XlXr2kdO3kFdD9ZiyA/APivAtBTUxeDGmvAd/iuzrjOUhXNX8zmuVYQGGtu
3C4y3IK9nFpFtAInfTGuwq5iRtfVOt0DmEEwF6ad8qofxigopRkKX0eWOgapeZtx
0PkUjv99bt2lc3Hrn0kA9ECUJ8X8pT3aZhVSuV/bZpwG1fqOTkNzFEQgm15PyMVN
v45z3/s6A4dJgZtGdlAB6c0/8kA+Ae4Fg5n65mQJqIoS2UqEQGf8FaTv0YpKYwc1
Qngd4iwJUUpcgm2DNey9
=A20Q
-----END PGP SIGNATURE-----

Re: [gentoo-dev] games.eclass

[Rich Freeman]

On Sat, Aug 22, 2015 at 3:33 AM, Daniel Campbell (zlg) <zlg@gentoo.org> wrote:
>
> 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.

You hit a few issues here, and without trying to solution any of them
I'll elaborate just a bit more, and I think it does make a case for
there being value in a team focused on games:
1. As there is more emphasis on CI/QA/etc how do we control quality on
proprietary packages?
2. How do we know if a proprietary ebuild even builds/works?
3. What is our stance on maintainership/responsiveness/etc on these
kinds of packages, since we're so dependent on maintainers who have
access?

Besides this there is also the fact that games tend to be demanding on
graphics drivers and opengl/sdl/etc.

>
> I think hasufell works on games... thoughts?
>

I've actually had a few contact me privately now expressing interest
in games, so perhaps there is an opportunity to "put the band back
together."  If anybody else would like to be among them please let me
know, and for those who have contacted me thanks and if you have
concerns with me sharing your name/address (but not any private
comments you have made) with the rest of the interested team please
let me know.

Also, thanks for those who have taken a bit of time to vent
frustrations both on the list and privately.  I'd like to see
something constructive come out of all this, as James recently
expressed.  I don't want to promise miracles though - I will say that
some frustrations I've seen expressed (by more than one on this topic
already) are the sorts of things you can find on blogs across the FOSS
world.

We do work that is important and often unpaid.  We tend to have deep
technical skills but exercise them in huge communities where
interpersonal issues become magnified.  We are activists and artists
and architects all at once.  We're changing the world in ways that are
often unnoticed not only by the public, but by ourselves.  This is
true of the entire FOSS world, but it seems especially true of Gentoo.

-- 
Rich

Re: [gentoo-dev] games.eclass

[hasufell]

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@gentoo.org> 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

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

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.

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.

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

Re: [gentoo-dev] games.eclass

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

On Sat, 22 Aug 2015 13:10:54 +0200
hasufell <hasufell@gentoo.org> wrote:

Great response, thanks!

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

I like unbundling but I also like this compromise. I wrote a wrapper
for launching Minecraft that allows the libraries to be unbundled but
because Minecraft updates are automatically downloaded by the official
launcher, I had to make it resilient to new dependencies suddenly
appearing and I also had to make it easy to disable entirely in the
event of problems. As things stand, it is woefully out of date due to
my other Java duties but I'll get there.

> Data ebuilds with cdinstall and optional gog sources are already
> available, see
> https://gitweb.gentoo.org/repo/gentoo.git/tree/games-fps/duke3d-data/duke3d-data-1.0-r2.ebuild
> https://gitweb.gentoo.org/repo/gentoo.git/tree/games-rpg/arx-fatalis-data/arx-fatalis-data-1.21-r2.ebuild

REQUIRED_USE="^^ ( cdinstall gog )"

That is great use of REQUIRED_USE. Last time I looked at this,
REQUIRED_USE didn't exist so I hadn't seen any examples but this is
exactly what I would have done.

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

I'm pleased to say I was thinking along the same lines. This gives me
confidence that I could contribute games without upsetting anybody, be
it alone or part of a team.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] games.eclass

[Rich Freeman]

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.

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

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@gentoo.org> 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-----

Re: [gentoo-dev] games.eclass

[hasufell]

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

Re: [gentoo-dev] games.eclass

[hasufell]

On 08/22/2015 08:01 PM, Daniel Campbell (zlg) wrote:
>> 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!
> 

It got fixed in several overlays and then later got force-fixed by QA.

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

A great example is games-strategy/openra, which is very shaky in terms
of stability and if you want to play it on LAN, you definitely want more
than one version to try out.

Another example are fps games like games-fps/urbanterror where a lot of
servers still run older versions (and you might even want to play these
on LAN).

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

Things I think that need to stay the same, although they can be improved:
* strict review policies, because I don't think it makes a lot of sense
to not communicate (we already had that). We have git, we can
communicate quickly and double check each others ebuilds/fixes. Games
ebuilds in particular have a lot of pitfalls.
* the team should have the freedom to enforce their own set of policies
and guidelines to a certain extent
* the team should be the go-to guys when it comes to games ebuilds
(pretty similar to what we have with other projects already... ofc you
can maintain your own python/games package without the python/games
herd, but it's really not very good style)

Things that need to change
* communicate more and be more open to global discussions
* be more open to community collaborations (github PRs for example)
* be proactive... don't just wait that people contact you
* actually process membership applications and extend the team
* be more active on the wiki and create useful sites (e.g. I started
https://wiki.gentoo.org/wiki/Games)
* try to bring more GoG and humble bundle games to the tree
* have an official games overlay for packages that really cannot meet
our current minimum standards (or other trash/graveyard/WIP things)...
the main work/collaboration however should happen in the tree
* help improve steam gaming on gentoo, even if it's just documentation
* improve official gentoo gaming support channels in general

Re: [gentoo-dev] games.eclass

[Rich Freeman]

On Sat, Aug 22, 2015 at 4:47 PM, hasufell <hasufell@gentoo.org> wrote:
> So my point stands. Games require their own set of policies (and ebuild
> writing guidelines).

I think we're somewhat talking past each other.  I'm not debating that
it may be beneficial for games to have some specific policies, and
those should be taken as they come.  However, many of the examples
that are coming up don't really strike me as games-specific so much as
general issues that apply often to games.

Just take it one issue at a time, and think about both the tree and
games when you make them.  We can always revisit at the distro level
if necessary.


-- 
Rich