allowed uses of non-baseline CPU extensions

[Adam Borowski <kilobyte@angband.pl>]

Hi folks!
Recently, I've made a package "isa-support" to improve handling of cases
where support for extensions not included in an arch's baseline is required. 
I'm not sure if an install-time check is the best idea, but no one proposed
anything better, thus for now it's an improvement over crashing (or
semi-gracefully dying with an error message) at runtime.

But, Adrian Bunk warned that this makes violating the baseline too easy.
And indeed, I just noticed an attempt to use an extension in a way I don't
consider to be valid: #864012.  I understand the maintainer's reasoning,
and don't blame him for following recommendations of that package's
upstream, but it's not appropriate for what I assume our _unwritten_ rules
mean.  And here's the problem: I can't seem to find an explicit requirement
that packages must follow the baseline!  So let's discuss and make a policy.

The package in question, lepton, is a tool to losslessly recompress JPEG
files.  It does so faster if your CPU is equipped with SSE4.1, thus the
upstream build system hard-codes this requirement, even though it seems
that generic code paths are present, broken only by completely bogus
ifdeffage: it has gems like:

if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "ppc")
option(SSE_VECTORIZATION "SSE instructions" OFF)
else()
option(SSE_VECTORIZATION "SSE instructions" ON)
endif()
…
if(SSE_VECTORIZATION)
  set(VECTOR_FLAGS "-mssse3 -msse4.2")
else()
  set(VECTOR_FLAGS "")
endif()

(Needless to say, build status is mostly red.)

In this case, there's no reason to exclude older computers: x86 with no
SSE4.1 isn't rare (especially on AMD), and it's a legitimate use case:
people with weak computers also tend to have low bandwidth, so reducing
file size of photos is nice.


So, let's list packages that want non-baseline:
* multiple variants: package src:x provides x-unoptimized, x-sse3 and
  x-avx1048576.  Clearly legitimate and a good idea.
* useless on older CPUs: pcsx2 can't emulate its game console on hardware
  older than said console; scientific number-crunching software is pointless
  on a Pentium2.  Trying to provide baseline builds would be a pure waste
  of time of the packager, and archive space.
* not supported by upstream: chromium:i386 on !sse2, rust:armhf on !neon
  (now fixed).  Not a good thing but a maintainer often lacks resources
  to implement this h{im,er}self.
Then there is:
* generic variants exist but someone decided that using fancy extensions
  is "better" (it might even indeed be better on new CPUs, but...)


The above cases, at the first glance, seem to provide clear rules.  Too bad,
in all but the first case, there's no clear boundary.  Especially "not
supported by upstream": how much work can be expected from the maintainer?

Any thoughts?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities.     -- whitroth on /.