On 06/29/2016 04:02 PM, Rich Freeman wrote: > On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell <z...@gentoo.org> wrote: >> 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? > > Per-package install locations? Sounds like a possible future EAPI > feature? Of course, the real trick is when packages need to interact > and the files aren't in a fixed location. > > In general right now I don't think we have a blessed way to install > stuff in non-standard locations. Obviously you can fork an ebuild and > modify it, but if somebody wants to install KDE in /usr/kde/ and X11 > into /usr/X11R6/ there isn't a clean way to do it. > A conversation or two I've had about it pointed to EPREFIX or some other variable/function that (I was told) the Prefix team would know a bit more about. I'm not even looking for something supported, per se. Supporting ebuilds that can be installed anywhere is a bit much for maintainers to worry about. But having the ability to, and having it documented, would be great. Even if it's something like "Gentoo Linux does not officially support or endorse this method, but here's how to get it working". An EAPI bump may be nice on paper, but I have a feeling implementing it would be a pain to support tree-wide.
Does the Prefix team have any recommendations in that department? That's what I think this drama is about; changes being pushed from people who don't work on games, then leaving these game maintainers (and users) in the dark without a "correct" way to achieve what they're after. We can do better than that, and it's solvable in a technical manner, which is why I'm focused on it. --- On the political side... Do teams hold any authority (or veto power, whatever you want to call it) over their own ebuilds? Is it reasonable to rip functionality out from under a group of developers and tell them to deal with it? I think teams deserve autonomy over their own ebuilds, and should ideally follow QA guidelines *where reasonable*. Any good QA team should have iron-clad reasons behind their decisions, and answers for 'what-ifs' that exist outside of the ideal perfection that QA tends to operate in. Removing eclasses without really good reason and without replacements for missing use cases simply shouldn't happen. I wouldn't want that done to me, and I'd definitely not (knowingly) help someone else do it. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
