Consensus summary around changing GLIBC PPC64 LE ABI default to 2.17

[Brooks Moses]

[resending, plain-text only]

I think you've missed an important nuance in this description of the
alternatives:

On Fri, Jan 31, 2014 at 3:57 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> (b) Stay on 2.1[78] sources using GLIBC_2.1[89] default ABI and backport
>     all 2.1[89] symbols to produce a 2.1[78]-based release whose ABI
>     is identical to the GLIBC_2.1[89] ABI released upstream.


Call that (b1).  There's also:

(b2) Stay on 2.1[78] sources using a GLIBC 2.1[89] default symbol
version, and do not backport additional symbols, thereby producing a
2.1[78]-based release whose ABI is a strict subset of the
GLIBC_2.1[89] ABI released upstream.

> - It is expected that neither SUSE nor Canonical want to try have a hybrid
>   symbol release either. Thus setting the ABI baseline to GLIBC_2.19
>   places them in the same position it places other 2.17-based distributions
>   with GLIBC_2.18 as the default ABI.

This may be expected for b1, but neither SUSE nor Canonical actually
objected to b2 and Adam strongly argued for it being a reasonable
solution.

There was an additional objection to b2, explained by Roland, that
having a strict subset of the GLIBC_2.1[89] ABI would result in
confusion in the RPM system about library dependencies of packages,
and similar lack of ability to detect mismatches at runtime, with the
result that a program that depended on a new-in-2.19 symbol would fail
at PLT resolution at some arbitrary time rather than failing in
startup.

With that said, I think the remainder of the description seems accurate.

- Brooks