Retire a package from Fedora i686 (not x86_64)

[Kevin Kofler]

Kalev Lember wrote:
> I wonder if it might be a good time to bump the i686 minimal
> requirements for F24 to include sse2. Not for performance reasons, but
> for compatibility: almost all developers are on x86_64 these days and
> i686 is pretty much just limping along. If we include sse2 on i686, that
> removes another difference between x86_64 and i686 and makes things
> easier for us as a downstream.

I don't think this difference is a real issue.

> Apparently quite a few upstreams these days consider sse2 as a minimal
> requirement and it seems more and more that Fedora packagers need to
> work this around if we don't follow the lead.

This is more of a problem.

This is only a minor annoyance where a portable fallback exists (we can just 
ship the portable C/C++ version in /usr/lib and the SSE2 version in 
/usr/lib/sse2, as we are doing with Qt 5 QtDeclarative). The real problem is 
software which has no portable fallback at all, such as Chromium/QtWebEngine 
or Darktable. This completely screws not only non-SSE2 x86, but also all 
secondary architectures, and in some cases such as Darktable, even the 
primary architecture ARM. It is unfortunate that the number of such non-
portable software seems increasing lately. Portability to any and all CPU 
architectures used to be a big selling point for Free Software. These days, 
more and more projects seem happy to sacrifice this on the altar of 
performance. :-(

I think dropping support for non-SSE2 in all of Fedora would send entirely 
the wrong message to those upstreams and only contribute to the surge of 
non-portable software.

That said, we need a formal policy to deal with such software, which IMHO 
should be treated just like an ExcludeArch, except that you should not 
actually ExcludeArch the package as long as it supports SOME CPUs of that 
architecture. It should still be put on the relevant ExcludeArch tracker 
though, and if a fix/workaround exists, applying it should be required.

> I don't think this is worth doing for performance reasons. I don't think
> a few percentage of possible gain in micro benchmarks is worth it, but
> if it saves some hundreds of hours of developer time for people who are
> working on Fedora and don't have to work around missing sse2, I'd say
> it's very well worth the cost of losing ancient CPU support.

That would unfortunately decrease the usefulness of the i686 distribution a 
lot. Given that we want to push users of 64-bit-capable machines to the 
x86_64 version, it would leave basically only one generation of x86 machines 
for the i686 distribution: the Pentium 4 Northwood generation, including one 
or two generation(s) of AMD CPUs from the same time. Add to that some newish 
low-end Atoms where they removed x86_64 support "to save power" (actually to 
introduce an artificial market segmentation), no idea how popular those are. 
Everything else that has SSE2 also has 64-bit.

Unfortunately, that prerogative ("all 64-bit-capable machines should use 64-
bit binaries") is not universally shared by upstreams. For example, Qt sees 
the primary target of their 32-binaries as being modern machines that would 
also support x86_64, but where the user elected to use 32-bit for whatever 
reason, not old 32-bit-only machines as we see it. That is the primary 
reason for the different stance on non-SSE2 support. (That said, Qt, outside 
of QtWebEngine, does not actually REQUIRE SSE2. They just enable its use by 
default.) My argument that the default option ought to be the safe, portable 
one (non-SSE2) was rejected on the grounds of performance on what they think 
are the vast majority of machines using 32-bit Qt (whereas I argued that it 
was only really one generation, but as I wrote above, they have a completely 
different conception of the purpose of 32-bit binaries).

        Kevin Kofler