Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17

[Brooks Moses <brooks dot moses at dpdx dot net>]

A few summarizing comments from what I hope is a neutral viewpoint -- my
only horse in this race is that I'd like the release to come out on 
time.  :)

On Thu, 30 Jan 2014 20:10:18 -0600, Steven Munroe wrote:
> So we have had a spirited debate and expressed our issues in a
> forthright manner. Clearly this is frustrating to many of you but I also
> see a developing consensus.
>
[...]
>       * No back-ports will be supported earlier then "default" set in
>         the official GLIBC-2.19 release.
>
> Does anyone disagree with the statements above?

To restate what I am seeing in the following thread, I think there is
considerable disagreement with this last point that you've listed above.  
(I admit that I don't fully understand what you mean by "supported", but
I am assuming that you mean what we expect vendors to be able to
reasonably support rather than proposing a backport on the FSF release
branches.)

By contrast, I think there _is_ a reasonable consensus that we should do
nothing that _technically_ prevents RedHat from making a 2.17 release
that supports powerpc64le.  There is debate about what that means, 
though.

Both Adam and Joseph are asserting that there should be no technical
problem with backporting these patches to a vendor 2.17 branch and 
leaving the symbol versions at 2.19.  Joseph cites prior experience with 
building a similar forward-versioned library some years ago.

Carlos, in his 23:36:48 -0500 email, said, "Adding 2.18 symbols to 2.17 
creates a hybrid whose macros still present the release as 2.17.  If I 
change the macros then it truly is a 2.18 release," and he went on to 
describe what I understand as the concerns of building a release from a 
modified 2.17 source branch but presenting it as a 2.18 release -- and, 
in particular, the unknown risk of whether that would break things that 
expect 2.18 behavior.

I have not seen anything that appears to be a _technical_ argument as to 
why there is a risk of putting 2.18-versioned symbols in a release that 
is otherwise presenting itself as a 2.17 version and has macros 
declaring it to be such.

My assumption at this point is that there is _no_ such purely technical
argument.  Carlos and Jeff have implied that RedHat's team is under
constraints that would prohibit doing so, and have implied that these
are for "management" reasons rather than "technical" reasons.  As I have
no connection to their team, I am free to speculate on what those might
be; one that IMO carries reasonable weight is that breaking the "you
need a glibc 2.18 or later package to provide symbols of 2.18 or later"  
invariant will confuse any users or support teams that run into a
problem with a 2.18-versioned symbol and are using their 2.17 library.

It would, I think, be good for someone from RedHat to describe a bit
more what precisely what their constraints _are_ and what their
alternate option is if the patch isn't approved, even if they are not at
liberty to share the reasons for those constraints or in a position to
debate them.

So, I think a reasonable framing for the remaining debate is:

* Are there technical reasons why RedHat is prevented from releasing a 
2.17 for powerpc64le given the status quo?

* Given that there appear to be (are?) non-negotiable non-technical
reasons why RedHat is prevented from doing so, is the rest of the
community willing to go through the pain to help them avoid whatever
horrible alternate option they will have to come up with?

- Brooks