25
glibc and glibc-eac-bin are in conflict (Installed glibc-eac-bin for Insurgency Sandstorm)
(self.linux_gaming)
Gaming on the GNU/Linux operating system.
Recommended news sources:
Related chat:
Related Communities:
Please be nice to other members. Anyone not being nice will be banned. Keep it fun, respectful and just be awesome to each other.
It does not mean much if this is 1 patch file or 20. Any amount of changes can be packed in a single patch file. I think OP was rather interested in the security perspective: does the eac patched glibc reduce security in any way? If not, what does it change at all?
Personally I would assume it does, because otherwise why would there be a separate patched version, instead of including all the changes in the main glibc everyone uses?
As per the patch file:
Per SO:
So it's just a patch to enable legacy stuff, with the potential drawback of slightly worse performance (which is given anyway in this case, because EAC bloat. Your usual software should be compatible with and therefore prefer the usual default of GNU hashtables, while EAC, that POS, will use the worser hashtable.)
Oh, thanks for looking it up. This sounds good and harmless.
Now it would be interesting to know if there's a legitimate need for this, or EAC just can't be bothered to fix their software.
I'm not that knowledgeable, but I guess it's EAC's fault: Apparently every application known to mankind, that uses glibc, is compatible with (the better) GNU hashtables. Except EAC. It may just be some incompatibility out of their reach, but then I wonder why every other program, native or run via wine, does not have this problem. My guess: They discovered that they could quietly remove GNU hashtable support, and therefore annoy most linux users, while just saying "your stuff is not compatible with my perfectly fine program".