The need for tcsetattr@GLIBC_2.42.1 and tcgetattr@GLIBC_2.42.1

[Florian Weimer]

I think we need symbol version to restrict the new tcsetattr and
tcgetattre behavior to newly linked applications.  This would achieve
near-perfect backwards compatibility with existing applications (but
not those that use dlsym).  I assume this include various industrial
control software that can't be recompiled.

(This change is not necessary for those architectures that already
received GLIBC_2.42 symbol versions.)

If we want to go down this route, this is what we can do make it more
manageable for distributions that have already recompiled against
glibc 2.42:

(a) Announce our plans on libc-announce.

(b) Add the new symbols to glibc 2.43, with the current behavior.

(c) Backport this change to release/2.42/master.

(d) Cut a 2.42.1 point release from the branch.  Distributions
    using glibc 2.42 should rebuild their own packages against
    this version.

(e) Change the behavior of the compatibility symbols to that of 
    glibc 2.41 for glibc 2.43.

(f) Backport this second change to release/2.42/master.

(g) Cut a 2.42.2 point release from the branch.  Distributions can
    upgrade to this version after they have rebuilt their own
    packages, achieving backwards compatibility with glibc 24.1.

Thoughts?