| 1 |
On 06/29/2016 04:02 PM, Rich Freeman wrote: |
| 2 |
> On Wed, Jun 29, 2016 at 6:47 PM, Daniel Campbell <zlg@g.o> wrote: |
| 3 |
>> I'm glad to see some reach-out here and taking responsibility for |
| 4 |
>> decisions. However, what does the QA team have to say about systems that |
| 5 |
>> want games on other media (such as an SSD or separate HDD), or wish to |
| 6 |
>> restrict the use of games on their system to certain accounts? |
| 7 |
>> |
| 8 |
>> Bumping EAPI won't magically allow those to happen, and removing the |
| 9 |
>> eclass *will* break those use cases. What's the "blessed" way to do those? |
| 10 |
> |
| 11 |
> Per-package install locations? Sounds like a possible future EAPI |
| 12 |
> feature? Of course, the real trick is when packages need to interact |
| 13 |
> and the files aren't in a fixed location. |
| 14 |
> |
| 15 |
> In general right now I don't think we have a blessed way to install |
| 16 |
> stuff in non-standard locations. Obviously you can fork an ebuild and |
| 17 |
> modify it, but if somebody wants to install KDE in /usr/kde/ and X11 |
| 18 |
> into /usr/X11R6/ there isn't a clean way to do it. |
| 19 |
> |
| 20 |
A conversation or two I've had about it pointed to EPREFIX or some other |
| 21 |
variable/function that (I was told) the Prefix team would know a bit |
| 22 |
more about. I'm not even looking for something supported, per se. |
| 23 |
Supporting ebuilds that can be installed anywhere is a bit much for |
| 24 |
maintainers to worry about. But having the ability to, and having it |
| 25 |
documented, would be great. Even if it's something like "Gentoo Linux |
| 26 |
does not officially support or endorse this method, but here's how to |
| 27 |
get it working". An EAPI bump may be nice on paper, but I have a feeling |
| 28 |
implementing it would be a pain to support tree-wide. |
| 29 |
|
| 30 |
Does the Prefix team have any recommendations in that department? |
| 31 |
|
| 32 |
That's what I think this drama is about; changes being pushed from |
| 33 |
people who don't work on games, then leaving these game maintainers (and |
| 34 |
users) in the dark without a "correct" way to achieve what they're |
| 35 |
after. We can do better than that, and it's solvable in a technical |
| 36 |
manner, which is why I'm focused on it. |
| 37 |
|
| 38 |
--- |
| 39 |
|
| 40 |
On the political side... |
| 41 |
|
| 42 |
Do teams hold any authority (or veto power, whatever you want to call |
| 43 |
it) over their own ebuilds? Is it reasonable to rip functionality out |
| 44 |
from under a group of developers and tell them to deal with it? |
| 45 |
|
| 46 |
I think teams deserve autonomy over their own ebuilds, and should |
| 47 |
ideally follow QA guidelines *where reasonable*. Any good QA team should |
| 48 |
have iron-clad reasons behind their decisions, and answers for |
| 49 |
'what-ifs' that exist outside of the ideal perfection that QA tends to |
| 50 |
operate in. |
| 51 |
|
| 52 |
Removing eclasses without really good reason and without replacements |
| 53 |
for missing use cases simply shouldn't happen. I wouldn't want that done |
| 54 |
to me, and I'd definitely not (knowingly) help someone else do it. |
| 55 |
-- |
| 56 |
Daniel Campbell - Gentoo Developer |
| 57 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
| 58 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
Archives