On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer <fweimer(a)redhat.com> wrote:
On 06/04/2018 05:55 PM, Jeff Backus wrote:
> Would you please provide more detail on what problem or problems we are
> trying to solve? Is this purely for efficiency reasons?
>
Mainly developer efficiency. There will be fewer test suite problems due
to excess precision (a bunch of packages carry patches which introduce
-ffloat-store on i686 to work around them). Packagers will not have to
figure out a way how to build for compatibility with non-SSE2 systems
(which some upstreams do not support anymore).
Furthermore, the divergence from downstream is troubling to Red Hatters
for various reasons. (Red Hat Enterprise Linux 7 already underwent a
similar change.)
Thanks for the insight. Yes, I can see the advantages. However, have things
really gotten so bad that it justifies ejecting part of the community? Yes,
a minor part of the community, but a part of the community none the less.
As you mentioned, the excess precision issue has a known work around. And
for packages where upstream does not support non-SSE2, packagers can raise
a flag with the x86 SIG. If there isn't enough interest or bandwidth to add
support for non-SSE2 systems, then I think it is perfectly reasonable to
add a note in the package description and move on. I believe packages such
as Dark Table already do this?
Until (unless?) we have data indicating that this is a major drain on
community resources, I'd push back on a change that actively excludes part
of the community. Now, if we do have data indicating that supporting
non-SSE2 systems with the i686 architecture is a not-insignificant burden
on the community, then I ask that this proposal be updated to include a
solution that allows us to not push out part of the community, e.g. Ajax's
i586 suggestion.
Not trying to be quarrelsome. I understand the desire to focus efforts,
however, I hope we can also appreciate the concerns of those of us with
currently supported hardware that would be affected by this proposal.
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus