Re: allowed uses of non-baseline CPU extensions
- Date: Thu, 5 Oct 2017 11:01:42 +0800
- From: Paul Wise <pabs@xxxxxxxxxx>
- Subject: Re: allowed uses of non-baseline CPU extensions
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? :)