New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/pull/34902#issuecomment-1278144921

Comment:
We should notice that the guys at Proton say to utilize Flatpak, if EAC is the only concern, which seems confirmed to be working well:

https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1204399354

Also, some stuff about the DT_HASH stuff worth mentioning:

_Did glibc 2.36 need a release note about dropped -Wl,--hash-style=both? Game users affected by the problem might argue that this was a high profile change and a deprecation or warning notice was needed. I disagree.
I beg that you read Carlos's summary. DT_HASH is a protocol between a linker and a dynamic loader. It is not intended to be consumed by a random non-standard ELF consumer. In addition, 16 years have been sufficiently long for any non-standard ELF consumer to know that DT_HASH has been mostly eliminated from Linux distributions. The glibc change removed one remnant DT_HASH use. It really was not as impactful as other changes in glibc 2.36._

_Is_ _DT_HASH_ _optional in the generic ABI?_

_If one reads much from the generic ABI wording, it says "mandatory", and therefore it is not optional. Does this make sense?_

_Technically a dynamic loader does not need a hash table to perform symbol lookup. It can start at the dynamic symbol table beginning specified by DT_SYMTAB, and scan to the end. Wait, in the absence of DT_HASH (DT_GNU_HASH is an extension, we want a way without an extension), there is no reliable way to get the number of dynamic symbol table entries. I tend to think this is outside of the generic ABI's business to require something. An ELF object can freely use an extension to provide the information. Specifying things in such a verbatim way is not ELF's spirit. Michael Matz disagrees in a [reply](https://groups.google.com/g/generic-abi/c/th5919osPAQ/m/uGSA05KIAgAJ) to "Making DT_HASH optional?"._

Source : https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash

I don't know about restoring something that appears to be closer to an ABI detail/extension, not even a proper component, that has been **16 YEARS** in deprecation. 

Are there security/performance concerns by proceeding with such a restoration? 
Is it even worth the hassle, since it's only relevant for a few entertainment products, for which a workaround also exists?
Why hasn't EAC been updated by those who should update it after several weeks, and why such responsibilities should otherwise fall upon distro maintainers?

Worth also noting that if EAC is not updated, Proton devs may eventually produce some other workaround themselves, as they do with most stuff anyway. 

Worth also noting that things appear to work for some, as confirmed by a recent comment, hence EAC is only broken in some specific situations:
https://github.com/void-linux/void-packages/pull/34902#issuecomment-1278117823

At the very least it should be examined what Arch devs are doing, if any problems are propping up, and for how long they are considering to proceed with such restorations (I doubt they'll do this for infinity and beyond).