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

[Michał Górny]

On Wed, 29 Jun 2016 22:37:27 -0700
Daniel Campbell <zlg@g.o> wrote:

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

Wiki is public. You are free to provide useful information if you like.
I don't feel like working on unsupported hacks that won't work reliably
and don't give much benefit to anyone. Just please keep that on
a separate page so that people don't think it's officially supported.

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

So why are you mentioning it? It looks like you jump out of the blue
like your life suddenly stopped to make sense, and go accusing random
people of being part of a process that started a few years back.

The games.eclass design supported many corner cases. They were weighed,
and it was decided that we prefer to go for uniformity, standards
compliance and simplicity, rather than working on support for a few
corner cases on non-clearly selected packages.

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

I either agree or disagree. If I disagree, I enter the discussion or
start it as necessary, etc. It's all in the procedures.

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

You are comparing two completely different changes. We are not
*breaking* user's systems. Systems will still boot, games will still
work.

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

Are you talking about user or developer documentation? Because I'm
really lost in your argumentation.

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