Re: [gentoo-dev] [QA] Official support for migrating ebuilds out of games.eclass

[Daniel Campbell]

On 06/29/2016 10:11 PM, Michał Górny wrote:
> On Wed, 29 Jun 2016 15:47:43 -0700
> Daniel Campbell <zlg@g.o> wrote:
>
>> On 06/29/2016 10:11 AM, Michał Górny wrote:
>>> Hello, everyone.
>>>
>>> Over half a year has passed since Council decided upon the fate of
>>> games in Gentoo. Over that period, the games team has neither showed
>>> any will to respect the Council decisions, nor officially appealed to
>>> them.
>>>
>>> For this reason, the QA team would like to officially start supporting
>>> the migration of ebuilds out of games.eclass. Any developer wishing to
>>> help is more than welcome to take any games.eclass ebuild, bump its
>>> revision and remove the games.eclass-specific bits from it. Updating to
>>> EAPI 6 would also be welcome. A short update guide is provided at
>>> the end of mail.
>>>
>>> Please note that since this is considered a matter of QA action with
>>> a long waiting period, no explicit approval from games team is
>>> necessary to commit the conversion, nor games team is allowed to reject
>>> or revert such commits as long as they are valid.
>>>
>>> If you need any help doing that and the games team refuses to provide
>>> it, please do not hesitate to contact me or ask in #gentoo-qa. If you
>>> are interested in helping out with games, feel free to join games team
>>> since it still lacks new members.
>>>
>>> Thank you for all the help.
>>>
>>>
>>> Migration notes
>>> ---------------
>>>
>>> TL;DR: nothing special required, remove games.eclass and all
>>> unnecessary games.eclass customization, and follow upstream. Make sure
>>> not to break stuff.
>>>
>>>
>>> The Council decisions can be summarized the following way:
>>>
>>> 1. The 'games' group, formerly used to control access to games, must
>>> not be used. Games should be executable for all users like any other
>>> program [1].
>>>
>>> 1a. For score files and similar writable shared data, the 'gamestat'
>>> group (enewgroup gamestat 36) can be used. The old 'games' group is not
>>> appropriate since sysadmins were expected to add users to it which
>>> defeated its purpose.
>>>
>>> 2. Gentoo path customization for games must be removed and regular
>>> install locations (without explicit control via GAMES_* variables)
>>> should be used [2]:
>>>
>>> 2a. /usr/games and /etc/games directories are forbidden,
>>>
>>> 2b. /usr/share/games can be used for data if that directory is used
>>> upstream,
>>>
>>> 2c. /var/games can be used for shared writable data.
>>>
>>>
>>> This is mostly achieved through removing games.eclass inherit,
>>> customization specific to it and replacing the helpers with generic PMS
>>> helpers (e.g. egamesconf -> econf, dogamesbin -> dobin).
>>> The 'gamesowners', 'gamesperms', 'prepgamesdirs' calls should be
>>> removed altogether.
>>>
>>> In some cases it will also be beneficial to remove patching added to
>>> support non-standard locations.
>>>
>>> Please remember to always rev-bump and not edit in place, to ensure
>>> proper upgrade. When dealing with dependencies, please make sure to
>>> check if the package does not rely on dependency installing data in
>>> a specific location. If that is the case, then you need to use
>>> appropriate >= deps to ensure clean upgrade.
>>>
>>> If you would like to report bugs requesting games.eclass removal,
>>> please make them block the tracker [3].
>>>
>>>
>>> [1]:https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
>>> [2]:https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
>>> [3]:https://bugs.gentoo.org/show_bug.cgi?id=574082
>>>
>> I'm glad to see some reach-out here and taking responsibility for
>> decisions. However, what does the QA team have to say about systems that
>> want games on other media (such as an SSD or separate HDD), or wish to
>> restrict the use of games on their system to certain accounts?
>>
>> Bumping EAPI won't magically allow those to happen, and removing the
>> eclass *will* break those use cases. What's the "blessed" way to do those?
>
> If you want to do custom stuff, you're on your own. There are tricks to
> do that (package.env, bashrc). Don't expect developers to patch packages
> to satisfy your corner case.
>

Why not document those tricks in the same section of the wiki that
indicates games.eclass's deprecation? A heads-up with a link?
_Something_. This isn't my use case, but we owe it to users to give them
ways forward when we break things, even if they aren't what we
personally use. If another developer (or team of developers) rendered
your use case(s) unsupported or flippantly wrote it off as a corner case
(with no documentation on restoring your previous use case), what would
you do?

Other breakages have been handled much better, such as the separate /usr
switch. Mentions of that were almost always followed up with "If you
wish to keep this, use an initramfs". That is an example of breakage
handled correctly: the change is explained, use cases that would break
were identified, and a way was given to users of that use case to move
forward and remain current.

Your handling of this eclass deprecation is little more than a heads-up,
"We're breaking your use case and we don't consider it worth writing a
paragraph's worth of documentation to guide you after the switch." Is
that what you find acceptable? Would you support a developer doing that
to another part of the tree?

Other changes in Gentoo have come along that were handled better *and*
were more impactful. This situation deserves no less consideration.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6