On Fri, 24 Aug 2018 10:13:42 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> I think an exp arch is also overkill. How many packages simply can't > be built for i486? I think a profile+masking makes a lot more sense > than an entire new level of QA that touches every ebuild in the tree > because there might be a few packages that don't work on 25 year old > hardware. In response to other conversations on #gentoo-x86, I think neither are needed any more. All that's needed to target this set is as follows: 1. Focus on the problem in terms of CPU instruction feature sets and memory limitations. 2. Make sure packages that don't work on i586 natively due to lack of instructions, and require adjustment, utilize CPU_FLAGS_X86 to expose this issue, ( eg: sse, mmx, cmov ) 3. Make the CPU_FLAGS_X86 generator tool emits the ideal values when run locally on a given processor. 4. For people targeting minimal should-at-least-work-on-i586/i486 binary images, setting CPU_FLAGS_X86="-*" should be recommended. 5. For people targeting physically ancient platforms with binary media, it might be pertinent to standardize on some sort of USE flag to indicate to applicable packages to optimize for runtime-memory-constrained environments. Or something along those lines. This should avoid all the downsides of new-arches/new profiles, while still allowing ebuilds to introspect and customize themselves as needed. Additionally, the features not being bound to a profile means they can be mixed and matched across profiles, so a memory-constrained environment targeting i686/mips/arm can use the same controls. And users who have, for example, CPUs' *with* the cmov instruction, but an inferior/slow implementation, can opt-out of using that instruction. And then using these tools we can throw minimal-flag-sets and minimal-memory at stage builds.
pgpbea3p7AHzh.pgp
Description: OpenPGP digital signature
