Don't add nis subdir for new architectures

  For future architectures, sysdeps/unix/inet no longer implies building the
nis subdirectory, and --enable-obsolete-nsl is ignored.

	* sysdeps/unix/inet/Subdirs: Remove nis.
	* sysdeps/unix/bsd/Subdirs: New file.
	* sysdeps/unix/sysv/linux/aarch64/Subdirs: New file.
	* sysdeps/unix/sysv/linux/alpha/Subdirs: New file.
	* sysdeps/unix/sysv/linux/arm/Subdirs: New file.
	* sysdeps/unix/sysv/linux/hppa/Subdirs: New file.
	* sysdeps/unix/sysv/linux/i386/Subdirs: New file.
	* sysdeps/unix/sysv/linux/ia64/Subdirs: New file.
	* sysdeps/unix/sysv/linux/m68k/Subdirs: New file.
	* sysdeps/unix/sysv/linux/microblaze/Subdirs: New file.
	* sysdeps/unix/sysv/linux/mips/Subdirs: New file.
	* sysdeps/unix/sysv/linux/powerpc/Subdirs: New file.
	* sysdeps/unix/sysv/linux/riscv/Subdirs: New file.
	* sysdeps/unix/sysv/linux/s390/Subdirs: New file.
	* sysdeps/unix/sysv/linux/sh/Subdirs: New file.
	* sysdeps/unix/sysv/linux/sparc/Subdirs: New file.
	* sysdeps/unix/sysv/linux/x86_64/Subdirs: New file.
	* manual/install.texi: Update --enable-obsolete-nsl.
	* INSTALL: Regenerate.
---
 INSTALL                                    | 4 +++-
 NEWS                                       | 4 ++++
 manual/install.texi                        | 2 ++
 sysdeps/unix/bsd/Subdirs                   | 1 +
 sysdeps/unix/inet/Subdirs                  | 1 -
 sysdeps/unix/sysv/linux/aarch64/Subdirs    | 1 +
 sysdeps/unix/sysv/linux/alpha/Subdirs      | 1 +
 sysdeps/unix/sysv/linux/arm/Subdirs        | 1 +
 sysdeps/unix/sysv/linux/hppa/Subdirs       | 1 +
 sysdeps/unix/sysv/linux/i386/Subdirs       | 1 +
 sysdeps/unix/sysv/linux/ia64/Subdirs       | 1 +
 sysdeps/unix/sysv/linux/m68k/Subdirs       | 1 +
 sysdeps/unix/sysv/linux/microblaze/Subdirs | 1 +
 sysdeps/unix/sysv/linux/mips/Subdirs       | 1 +
 sysdeps/unix/sysv/linux/powerpc/Subdirs    | 1 +
 sysdeps/unix/sysv/linux/riscv/Subdirs      | 1 +
 sysdeps/unix/sysv/linux/s390/Subdirs       | 1 +
 sysdeps/unix/sysv/linux/sh/Subdirs         | 1 +
 sysdeps/unix/sysv/linux/sparc/Subdirs      | 1 +
 sysdeps/unix/sysv/linux/x86_64/Subdirs     | 1 +
 20 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 sysdeps/unix/bsd/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/aarch64/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/alpha/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/arm/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/hppa/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/i386/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/ia64/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/m68k/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/microblaze/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/mips/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/powerpc/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/riscv/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/s390/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/sh/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/sparc/Subdirs
 create mode 100644 sysdeps/unix/sysv/linux/x86_64/Subdirs
  

On Wed, Jul 4, 2018 at 11:31 AM, Andreas Schwab <schwab@suse.de> wrote:
> For future architectures, sysdeps/unix/inet no longer implies building the
> nis subdirectory, and --enable-obsolete-nsl is ignored.

This change appears to be technically correct for the existing Linux
ports.  I don't have enough context to assess whether it might have
negative consequences, but I support it in principle.

I have two minor concerns:

1) Should the nis directory continue to be built by default for the
existing Hurd port (ix86-gnu)?  I don't think that port has a stable
ABI yet, so perhaps not, but I'd like to hear that from Samuel.

2) The text added to install.texi / INSTALL is unclear:

> --- a/manual/install.texi
> +++ b/manual/install.texi
> @@ -229,6 +229,8 @@ compatibility and the NSS modules libnss_compat, libnss_nis and
>  libnss_nisplus are not built at all.
>  Use this option to enable libnsl with all depending NSS modules and
>  header files.
> +This option has no effect on architectures that were added after the
> +2.27 release.

as it could mean either that --enable-obsolete-nsl mode cannot be
turned *on* for new architectures, or that it cannot be turned *off*.
I suggest

  Architectures added after the 2.27 release will not even build libnsl as a
  compatibility library; this option has no effect on those architectures.

zw
  

* Andreas Schwab:

> For future architectures, sysdeps/unix/inet no longer implies building the
> nis subdirectory, and --enable-obsolete-nsl is ignored.

I think we should remove --enable-obsolete-rpc and
--enable-obsolete-nsl altogether, and no longer include the compat
symbols for new architectures, as usual.
  

On Jul 17 2018, Florian Weimer <fw@deneb.enyo.de> wrote:

> * Andreas Schwab:
>
>> For future architectures, sysdeps/unix/inet no longer implies building the
>> nis subdirectory, and --enable-obsolete-nsl is ignored.
>
> I think we should remove --enable-obsolete-rpc and
> --enable-obsolete-nsl altogether,

Feel free to submit a patch.  That is an independent change.

> and no longer include the compat symbols for new architectures, as
> usual.

We still need the compat libnsl for the existing architectures.  This is
what my patch addresses.

Andreas.
  

* Andreas Schwab:

> On Jul 17 2018, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> * Andreas Schwab:
>>
>>> For future architectures, sysdeps/unix/inet no longer implies building the
>>> nis subdirectory, and --enable-obsolete-nsl is ignored.
>>
>> I think we should remove --enable-obsolete-rpc and
>> --enable-obsolete-nsl altogether,
>
> Feel free to submit a patch.  That is an independent change.

Conceptually it's not.  If there are distributions which still want to
build the old interfaces, with your patch, they will not be able to
build newer glibc versions for the affected architectures.  That's why
I think we need consensus first whether distributions still need those
configure options.
  

On Wed, 4 Jul 2018, Andreas Schwab wrote:

> +* Future architecture ports will no longer build a compatibility libnsl
> +  shared library, and --enable-obsolete-nsl will be ignored on those
> +  architectures.

> +This option has no effect on architectures that were added after the
> +2.27 release.

There's ambiguity here about new ABIs for existing architectures.  (Since 
they should be like new architectures regarding symbol versions, they 
should also be like new architectures in this regard.)
  

On Jul 17 2018, Joseph Myers <joseph@codesourcery.com> wrote:

> On Wed, 4 Jul 2018, Andreas Schwab wrote:
>
>> +* Future architecture ports will no longer build a compatibility libnsl
>> +  shared library, and --enable-obsolete-nsl will be ignored on those
>> +  architectures.
>
>> +This option has no effect on architectures that were added after the
>> +2.27 release.
>
> There's ambiguity here about new ABIs for existing architectures.  (Since 
> they should be like new architectures regarding symbol versions, they 
> should also be like new architectures in this regard.)

The intent is to exclude nis for all architectures and ABIs that have a
base version of 2.28 or later.

Andreas.
  

On Wed, 18 Jul 2018, Andreas Schwab wrote:

> On Jul 17 2018, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> > On Wed, 4 Jul 2018, Andreas Schwab wrote:
> >
> >> +* Future architecture ports will no longer build a compatibility libnsl
> >> +  shared library, and --enable-obsolete-nsl will be ignored on those
> >> +  architectures.
> >
> >> +This option has no effect on architectures that were added after the
> >> +2.27 release.
> >
> > There's ambiguity here about new ABIs for existing architectures.  (Since 
> > they should be like new architectures regarding symbol versions, they 
> > should also be like new architectures in this regard.)
> 
> The intent is to exclude nis for all architectures and ABIs that have a
> base version of 2.28 or later.

Yes, I agree that's the right intent, but I'm not convinced it's clear 
from the documentation wording that e.g. RV32, or RV64 with 'F' ABI, would 
be a case where the option has no effect.
  

On Jul 18 2018, Joseph Myers <joseph@codesourcery.com> wrote:

> Yes, I agree that's the right intent, but I'm not convinced it's clear 
> from the documentation wording

It can be improved of course.

Andreas.