On Thu, Oct 5, 2017 at 9:52 AM, Adam Borowski wrote: > Any thoughts?
A better place to put isa-support might be in an apt plugin that detects packages being installed that declare for example CPU-Flags: SSE4.1 and prevents installing them unless in a chroot (for d-i or debootstraps) and has an option to disable that blockage. Zero idea if apt has a hook that could be used for this. Anything that generates different code depending on the instructions supported by the build CPU is going to break reproducible builds. So whatever mechanism is used, it needs to be deterministic. We need to get a wide variety of CPUs doing reproducible builds verification to detect failures in this area. I'd like to see CMAKE_SYSTEM_PROCESSOR and similar be deprecated upstream because of that. Obviously runtime choice of CPU instructions is best (and as Ben says FMV is a good way to do that), but if upstream doesn't support that and has some lofty CPU requirements, I don't think we can force maintainers to spend time on migrating to runtime detection or other solutions. Probably the policy should be that the package description and other metadata (isa-support deps for eg) must document any CPU requirements above the baseline. Does anyone have thousands of ancient slow CPUs to reproduce all the builds and run autopkgtests on? :) -- bye, pabs https://wiki.debian.org/PaulWise
